您对重新抛出异常的看法 [英] Your opinion about rethrowing exceptions
问题描述
在我看来，在不提供额外信息的情况下重新抛出异常
是一种浪费
例如：
在我看来错了：
A：
公共子DoSomeStuff（）
尝试
做它
Catch ex As Exception
抛出新例外（ex.tostring）
结束尝试
结束子
在我看来似乎合理
B：
Public sub DoSomeStuff（）
试试
做吧
Catch ex As Exception
抛出新例外（关于此例外的额外信息，ex）
结束尝试
结束子
在我看来，如果这个方法在父异常处理程序中最常见
C：
公共子DoSomeStuff（）
做它
结束子
请注意这三个版本是在父异常中调用的
处理程序
但是这里的一些人似乎坚持使用版本一个
我告诉他们这是浪费资源，另一方面他们告诉我我b $ b错了，因为异常不会被打扰，如果你不重新抛出（
ofcourse我测试了这个和我的comp它确实如此）
我想听听你对这个问题的看法/>
问候
米歇尔
他们可能改变了一些东西他们的IDE（我相信有一个停止在
未处理的异常）复选框）。在IDE运行
时它们是否具有相同的行为？
如果你想处理资源它仍然是有用的（这是什么
" using"确实如此）但是抛出一个新的异常和
抛出相同的异常之间存在差异（省略catch子句就可以完成这项工作）。
当然，如果你什么都不做，那么首先要抓住
例外是没有意义的（它应该被应用程序全局捕获
异常处理程序）。
" Michel Posseth [MCP]" < Mi ************** @discussion.microsoft.comaécrit
dans le message de news：
67 ********* *************************@microsoft.com ...
在我看来，在不提供额外额外的情况下重新抛出异常
信息
是一种浪费
例如：
在我看来错了：
A：
Public sub DoSomeStuff（）
试试
做它
Catch ex As Exception
抛出新例外（ex.tostring）
结束尝试
结束sub
在我看来似乎合理
B：
Public sub DoSomeStuff（）
尝试
做它
Catch ex As Exception
抛出新例外（关于此例外的额外信息，ex）
结束尝试
结束子
在我看来，如果这种方法处于父异常中最常见
处理程序
C：
公共子DoSomeStuff（）
做它
结束子
请注意三在父母中调用版本
例外
处理程序
但是这里的一些人似乎坚持使用版本A
我告诉他们这是浪费资源，另一方面他们告诉我
i
错了，因为异常不会被打乱，如果你不重新说明
（
ofcourse我测试了这个和我的comp它确实如此）
我想听到你对这个问题的看法
问候
米歇尔
Michel Posseth [MCP]写道：
在我看来，重新抛出异常而不提供额外的补充
信息是总浪费
同意。抓住一个例外只是为了再次重新抛出它通常相当无意义的b $ b。也许你可能想在Throw行上设置一个断点，所以你可以拦截那个特殊的异常，而不是在未处理的异常选项上使用break
，但即便如此这只是一个调试
功能而不是作为项目范围标准采用的东西。
我也想在代码中指出一个问题然而你发布了......两个
你的例子A和B实际上抛出了新的异常，而不是重新抛出
他们捕获的异常。在示例B的情况下，这具有能够添加额外信息的
优势，但是这种效果是
你丢失了到目前为止的调用堆栈当新的一个被抛出时，被添加到例外
。如果你确实想要捕获并重新抛出
异常，你应该只使用投掷。声明没有任何参数
：
\\\
Public sub DoSomeStuff（）
尝试
做它
Catch ex As Exception
投掷
结束尝试
结束分
///
上例中异常处理的效果恰好是
就像没有使用Try / Catch块一样。
如果编译器对Release
版本进行优化，我不会感到惊讶，但是我还没有测试过这一点。
-
（O）enone
嗯...
好像你们都同意我的意见
你可能已经明白这是来自于与我的
同事讨论，他们正在捕捉并抛出异常而不提供额外的
信息，如例A：
他们告诉我，我做错了，（因为我没有猫在io例程中，但在父母的调用中，总是出现错误
。
我告诉他们他们浪费了资源而没有使用功能
感谢你们对你们这两个主题的关注......
问候
米歇尔
Oenone写道：
Michel Posseth [MCP]写道：
在我看来，在不提供额外额外的情况下重新抛出异常
信息总浪费
同意。抓住一个例外只是为了再次重新抛出它通常相当无意义的b $ b。也许你可能想在Throw行上设置一个断点，所以你可以拦截那个特殊的异常，而不是在未处理的异常选项上使用break
，但即便如此这只是一个调试
功能而不是作为项目范围标准采用的东西。
我也想在代码中指出一个问题然而你发布了......两个
你的例子A和B实际上抛出了新的异常，而不是重新抛出
他们捕获的异常。在示例B的情况下，这具有能够添加额外信息的
优势，但是这种效果是
你丢失了到目前为止的调用堆栈当新的一个被抛出时，被添加到例外
。如果你确实想要捕获并重新抛出
异常，你应该只使用投掷。声明没有任何参数
：
\\\
Public sub DoSomeStuff（）
尝试
做它
Catch ex As Exception
投掷
结束尝试
结束分
///
上例中异常处理的效果恰好是
就像没有使用Try / Catch块一样。
如果编译器对Release
版本进行优化，我不会感到惊讶，但是我还没有测试过这一点。
-
（O）enone
In my opinion rethrowing exceptions without providing anny extra information
is a totall waste
Examples :
in my opinion wrong :
A:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception(ex.tostring )
End Try
End sub
in my opinion plausible
B:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception("extra info about this exception ",ex)
End Try
End sub
In my opinion most common if this method is in a parent exception handler
C:
Public sub DoSomeStuff()
do it
End sub
please note that the three versions are beeing called in a parent exception
handler
However some people here seem to stick with version A
I told them this is a waste of resources , they on the other hand tell me i
am wrong , as the exception would not be bubled up , if you do not rethrow (
ofcourse i tested this and on my comp it does )
I would like to hear your throughts about the subject
Regards
Michel
They perhaps changed something in their IDE (I believe there is a "stop on
unhandled exception" checkbox). Do they have the same behavior when running
outise of the IDE ?
It can still be usefull if you want to dispose resources (this is what
"using" does) but there is a difference between throwing a new exception and
throwing the same exception (omitting the catch clause will do the job).
Of course if you do nothing at all, there is no point in catching the
exception in the first place (it should be catched by the application global
exception handler).
"Michel Posseth [MCP]" <Mi**************@discussions.microsoft.coma écrit
dans le message de news:
67**********************************@microsoft.com...In my opinion rethrowing exceptions without providing anny extra
information
is a totall waste
Examples :
in my opinion wrong :
A:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception(ex.tostring )
End Try
End sub
in my opinion plausible
B:
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw New Exception("extra info about this exception ",ex)
End Try
End sub
In my opinion most common if this method is in a parent exception
handler
C:
Public sub DoSomeStuff()
do it
End sub
please note that the three versions are beeing called in a parent
exception
handler
However some people here seem to stick with version A
I told them this is a waste of resources , they on the other hand tell me
i
am wrong , as the exception would not be bubled up , if you do not rethrow
(
ofcourse i tested this and on my comp it does )
I would like to hear your throughts about the subject
Regards
Michel
Michel Posseth [MCP] wrote:In my opinion rethrowing exceptions without providing anny extra
information is a totall wasteAgreed. Catching an exception just to rethrow it again it usually fairly
pointless. Perhaps you might want to put a breakpoint on the Throw line so
that you can intercept that particular exception rather than using the break
on unhandled exceptions option, but even then that''s just a debugging
feature and not something to adopt as a project-wide standard.
I also wanted to point out a problem in the code you posted however... Both
your examples A and B actually throw new exceptions, rather than rethrowing
the exception that they caught. In the case of example B this has the
advantage of being able to add extra information, but the effect of this is
that you lost the call stack that has so far been added to the exception
when the new one is thrown. If you did want to catch and rethrow the
exception, you should just use the "Throw" statement without any parameters
at all:
\\\
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw
End Try
End sub
///
The effects of the exception handling in the above example are exactly the
same as not using a Try/Catch block at all.
I wouldn''t be surprised if the compiler optimises this out for Release
builds, but I haven''t tested that to be sure.
--
(O)enone
Well ...
It seems like you both agree with me
As you probably understood this was coming from a discussion with my
colleguess who are catching and throwing exceptions without providing extra
information as in example A:
They told me i was doing it wrong , ( cause i did not catch the error at all
in the io routine but in the parent call ) .
I told them they wasted resources without anny functional use
Thanks for shining your light on the subject to you both
regards
Michel
"Oenone" wrote:
Michel Posseth [MCP] wrote:In my opinion rethrowing exceptions without providing anny extra
information is a totall waste
Agreed. Catching an exception just to rethrow it again it usually fairly
pointless. Perhaps you might want to put a breakpoint on the Throw line so
that you can intercept that particular exception rather than using the break
on unhandled exceptions option, but even then that''s just a debugging
feature and not something to adopt as a project-wide standard.
I also wanted to point out a problem in the code you posted however... Both
your examples A and B actually throw new exceptions, rather than rethrowing
the exception that they caught. In the case of example B this has the
advantage of being able to add extra information, but the effect of this is
that you lost the call stack that has so far been added to the exception
when the new one is thrown. If you did want to catch and rethrow the
exception, you should just use the "Throw" statement without any parameters
at all:
\\\
Public sub DoSomeStuff()
Try
do it
Catch ex As Exception
Throw
End Try
End sub
///
The effects of the exception handling in the above example are exactly the
same as not using a Try/Catch block at all.
I wouldn''t be surprised if the compiler optimises this out for Release
builds, but I haven''t tested that to be sure.
--
(O)enone
这篇关于您对重新抛出异常的看法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
