|
1
8
它是有效的(因为它将编译、构建和运行),但不是好的实践。
作为对编辑的响应,两个catch块都不会被命中。
如果
|
|
2
3
只会命中一个异常块。它们按顺序排列,所以如果
也就是说,如果您所做的只是重新引用异常,我可能根本不会在这里使用try/catch。这不是一个好的做法。至少,请确保在第二个catch中添加原始异常作为要创建的AuthenticationException的InnerException:
|
|
|
3
2
如果DoSomething抛出任何内容,则此代码将抛出AutheniticationException。如果DoSomething抛出AuthenticationException,则将是同一个异常,或者在任何其他情况下抛出新异常。
|
|
|
4
0
是的 如果你有不同的例外。(2个例外) 不 如果你希望第一个街区在第二个街区到达。(1个例外) |
|
|
5
0
不。两个挡块都不会被击中。 如果DoSomething抛出AuthenticationException,那么它将被捕获并重试。 如果DoSomething抛出任何其他异常,将抛出一个新的AuthenticationException,并显示消息“Hello”。 |
|
|
6
0
但是不应该在第二个catch中抛出新的AuthenticationException。 |
|
|
7
0
第二个块不会从第一个块捕获rethrown异常。 |
|
|
8
0
我可以看到捕捉和重新触发异常的一个好处是传递这样一个信息:“请求的操作没有成功,但系统状态基本上与尝试操作前一样。”虽然捕获内部例程中的所有异常并希望它们都不代表应导致主程序终止的问题有些令人讨厌,但我不确定哪种替代设计更好。人们可以在代码中乱扔: If Not Integer.TryParse(inputString, inputVar) Then
Throw New MyApp.FileLoadException("Whatever")
EndIf
但仅仅使用整数。解析并捕获发生的任何异常。在一个已知其预期原因的小范围内捕获和重铸一般异常远没有在更高级别上吞下一般异常那么邪恶。 |
|
|
A B · C#Excel自动调整列避免长文本时出错 1 年前 |
|
|
Megrez7 · C#ToArray转换合并为一行,导致数组元素更改 1 年前 |
|
Aycon · 在工厂方法中释放部分创建的对象的正确方法是什么? 1 年前 |
|
|
Sei · Avalonia/WPF将路由器传递到控制模板 1 年前 |