API10的严格语法strictPropertyInitialization的修改方法

通过实践，发现有两种修改方式均可编译通过，两种方法有什么推荐。

export class TestObj { 
  // API10下报错 
  res1: Resource; 
  // API10下报错 
  res?: Resource; 
}1.
2.
3.
4.
5.
6.

以上代码API10下编译报错：Property ‘res1’ has no initializer and is not definitely assigned in the constructor.

如下有两个改法，均可编译通过，请问两种改法的优劣和建议？

export class TestObj { 
  // 改法1 
  res1: Resource | null = null; 
  // 改法2 
  res2?: Resource; 
}1.
2.
3.
4.
5.
6.

HarmonyOS

mzshj

2024-05-30 21:55:03

1.1w浏览

回答 1

按赞同

按时间

薯条包装盒

推荐使用改法1，在使用时会有类型检查从TypeScript到ArkTS的适配规则，

强制进行严格类型检查规则：arkts-strict-typing

级别：错误

在编译阶段，会进行TypeScript严格模式的类型检查，包括：

noImplicitReturns,

strictFunctionTypes,

strictNullChecks,

strictPropertyInitialization。

TypeScript

// 只有在开启noImplicitReturns选项时会产生编译时错误 
function foo(s: string): string { 
  if (s != '') { 
    console.log(s) 
    return s 
  } else { 
    console.log(s) 
  } 
} 
let n: number = null // 只有在开启strictNullChecks选项时会产生编译时错误 
function foo(s: string): string { 
  console.log(s) 
  return s 
} 
let n1: number | null = null 
let n2: number = 01.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

在定义类时，如果无法在声明时或者构造函数中初始化某实例属性，那么可以使用确定赋值断言符!来消除strictPropertyInitialization的报错。使用确定赋值断言符会增加代码错误的风险，开发者需要保证该实例属性在被使用前已被赋值，否则可能会产生运行时异常。使用确定赋值断言符会增加运行时的类型检查，从而增加额外的运行时开销，所以应尽可能避免使用确定赋值断言符。使用确定赋值断言符将产生warning: arkts-no-definite-assignment。

class C { 
  name: string // 只有在开启strictPropertyInitialization选项时会产生编译时错误 
  age: number // 只有在开启strictPropertyInitialization选项时会产生编译时错误 
} 
let c = new C() 
ArkTS 
class C { 
  name: string = ‘’ 
  age!: number // warning: arkts-no-definite-assignment 
 
  initAge(age: number) { 
    this.age = age 
  } 
} 
let c = new C() 
c.initAge(10)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

相关约束：

使用具体的类型而非any或unknown不允许通过注释关闭类型检查。

2024-05-31 21:16:58

如何写精华回答，获更多曝光？

发布

51CTO

51CTO博客

51CTO学堂

API10的严格语法strictPropertyInitialization的修改方法

订阅鸿蒙技术特刊，精选内容抢先看