c# “最后” 仅在异常时运行的块
编辑:我已经查看了答案代码:没有他们做了我想做的事情(我已经检查过)。 似乎没有办法在本机 C# 中做我想做的事情。 我想这不是一场灾难,只是一种耻辱,因为 .NET 确实支持它(请参阅已接受的答案)。
谢谢大家。
我有这样的 C# 代码(测试框架的一部分,除了在调试器下之外永远不会运行),它指出它是为了避免实际捕获异常,因为这使得调试堆栈的展开部分中的代码变得非常痛苦。
Bool bad = true;
try
{
MightThrow();
bad = false;
}
finally
{
if(bad) DoSomeLoggingOnFailure();
//// Does not catch!!!!
//// exception continues to unwind stack.
//// Note that re throwing the exception is NOT
//// the same as not catching it in the first place
}
他们有更好的方法吗?
对于未捕获的异常,解决方案的行为必须与调试器下的行为完全相同。 它必须导致唯一的一次机会异常,并且调试器在异常最初抛出时中断,而不是在 catch 块中。
具体来说,我需要调试器针对未捕获的异常来停止内部 MightThrow。
以下不起作用,因为它无法让调试器在正确的位置中断
try { ... } catch { throw; }
,而这不起作用,因为它丢失了堆栈信息(并且也在错误的位置中断)。
try { ... } catch(Exception e) { throw e; }
Edit: I have looked at the answers code: NONE of them do what I want (I've checked). It would seem that there is no way to do what I want in native c#. I guess that's not a disaster just a shame given that .NET does support it (see accepted answer).
Thanks all.
I have c# code (part of a test framework that will never be run except under a debugger) like this who's point it to avoid actually catching the exception as that makes debugging the code in the unwound part of the stack a royal pain.
Bool bad = true;
try
{
MightThrow();
bad = false;
}
finally
{
if(bad) DoSomeLoggingOnFailure();
//// Does not catch!!!!
//// exception continues to unwind stack.
//// Note that re throwing the exception is NOT
//// the same as not catching it in the first place
}
is their a better way to do this?
A solution would have to behave exactly like that under the debugger with regards to un-caught exceptions. It would have to result in the only one first chance exception and the debugger breaking at the point that the exception was originally thrown, not in a catch block.
Specifically I need the debugger on un-caught exceptions to stop a in side MightThrow.
The following doesn't work because it fails to have the debugger break in the correct place
try { ... } catch { throw; }
And this doesn't work because it loses stack info (and also breaks in the wrong place).
try { ... } catch(Exception e) { throw e; }
I known that in D I could use a scope(failure)
block
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(17)
怎么样:
真的,这就是你所做的一切。 最后是用于无论是否发生异常都必须运行的事情。
[编辑:澄清]
根据您提到的评论,您希望继续引发异常而不修改其原始堆栈跟踪。 在这种情况下,您需要使用我添加的朴素的投掷。 这将允许异常在堆栈中继续向上,并且仍然允许您处理部分异常。 典型的情况可能是关闭网络连接或文件。
[第二次编辑:关于您的澄清]
我反对打破最佳实践(是的,这是部分处理异常的最佳实践)来为调试添加一些次要的价值。 您可以轻松检查异常以确定抛出异常的位置。
[最终编辑:你已经有了答案]
kronoz 已贴心地为您提供了您所寻求的答案。 不要违反最佳实践——正确使用 Visual Studio! 您可以将 Visual Studio 设置为在引发异常时准确中断。 以下是有关该主题的官方信息。
我实际上不知道这个功能,所以去给他接受的答案。 但是请不要仅仅为了方便自己调试而尝试以某种时髦的方式处理异常。 你所做的就是让自己面对更多的错误。
How about this:
Really, that's all you did. Finally is for things that must run regardless of whether an exception occurred.
[Edit: Clarification]
Based on the comments you've been mentioning, you want the exception to continue being thrown without modifying its original stack trace. In that case, you want to use the unadorned throw that I've added. This will allow the exception to continue up the stack and still allow you to handle part of the exception. Typical cases might be to close network connections or files.
[Second edit: Regarding your clarification]
I would argue against ever breaking a best-practice (and yes, this is a best-practice for partially handling exceptions) to add some minor value to your debugging. You can easily inspect the exception to determine the location of the exception throw.
[Final edit: You have your answer]
kronoz has thoughtfully provided you with the answer you sought. Don't break best practices -- use Visual Studio properly! You can set Visual Studio to break exactly when an exception is thrown. Here's official info on the subject.
I was actually unaware of the feature, so go give him the accepted answer. But please, don't go trying to handle exceptions in some funky way just to give yourself a hand debugging. All you do is open yourself up to more bugs.
如果您对调试器只是在异常发生的地方精确停止感兴趣,那么您是否考虑过第一次机会异常?
如果打开“工具”|“异常”,然后勾选“公共语言运行时异常”框,则调试器将在异常点停止,无论是否有任何 try/catch/finally 块。
更新:您可以通过展开“异常”对话框中的 [+] 树来指定要捕获的精确异常。 当然,每次发生指定类型的任何异常时它都会触发,即使在调试会话期间,您也可以随意打开和关闭它,因此请明智地使用使用断点你可以让它执行你的命令。 我成功地使用它来解决由于使用反射来实例化对象而产生的“调用的目标引发了异常”的问题。 在这种情况下非常有用的工具。 另请注意,据我所知,本地变量和堆栈跟踪应该完全可用(刚刚做了一个快速测试,它们可用),所以没有问题。
当然,如果您想记录日志,那么这超出了 IDE 调试器的范围; 在这种情况下,第一次机会例外对你没有帮助!
至少尝试一下; 我发现它们非常有用,并且它们可能比您想象的更适合您的问题。
If you're interested in the debugger simply stopping precisely where the exception occurred then have you considered first-chance exceptions?
If you open Tools|Exceptions then tick the Common Language Runtime Exceptions box, the debugger will stop at the point of exception regardless of any try/catch/finally blocks.
Update: You can specify the precise exception you wish to catch by expanding the [+] tree in the Exceptions dialog. Though of course it will fire every time any exception of the specified type[s] occur[s], you can switch it on and off at will even in the middle of a debugging session, so with judicious use of breakpoints you can get it to do your bidding. I used it successfully to get around the 'target of an invocation has thrown an exception' ball ache originating from using reflection to instantiate objects. Very useful tool in such circumstances. Also note the locals and stack trace should be firmly available as far as I recall (just did a quick test and they are available), so no problems there.
Of course if you want to log things then that is outside the scope of an IDE debugger; and in which case first-chance exceptions won't help you!
Give it a go at least; I found them very useful and they might be more appropriate for your issue than you think.
有什么问题:
What's wrong with:
对于只应在异常时运行的代码,请使用 catch 块:
For code that should only run on exceptions, use the catch block:
这就是你想要的。 它只会在发生错误时调用此方法,并且“throw”语句将在调用堆栈完好无损的情况下重新抛出异常。
This is what you want. It will only call this method when an error occurs, and the "throw" statement will re-throw the exception with the callstack intact.
仅在失败时运行的“finally”块称为“catch”(不带参数)。 :-)
现在,有一个小警告。 如果您希望为特定异常类型提供专门的“catch”情况,并拥有适用于所有异常的通用“catch”,则必须执行一些自定义逻辑。
因此,我会做类似的事情:
A "finally" block that runs only on failure is called "catch" (with no parameters). :-)
Now, there is a small caveat. If you want to have a specialised "catch" case for a particular exception type and have a generic "catch" that works for all exceptions, you'll have to do a bit of a custom logic.
Thus, I would do something like:
根据我的测试,到目前为止,每个示例都丢失了原始的 StackTrace。 这是一个应该适合您的解决方案。
Every example so far is losing the original StackTrace according to my tests. Here's a solution that should work for you.
只捕获“MightThrow”不抛出的异常怎么样?
How about only catching an exception that "MightThrow" does not throw?
让我以我理解的方式回顾一下您的需求:
为了满足您的第一个要求,您应该按照每个人建议的方式编写代码 - 使用无参数的 catch 和 throw。
为了在使用无参数 catch 时满足第二个要求,您可以将调试器配置为在引发异常时中断,而不仅仅是在存在未处理的异常时中断。 我怀疑你知道如何做到这一点,但为了答案的完整性,我将其放在这里:在 VS 中,你可以在 Debug -> 中执行此操作。 异常-> 公共语言运行时异常 -> 选中抛出复选框。
如果您知道您的应用程序会引发大量已处理的异常,那么这可能不适合您。 此时,满足第一个要求的唯一选择是编写最终用于异常日志记录的代码,或者按照 Greg Beech 的建议查看直接 IL 发出路径。
然而,finally 代码是否被执行取决于您使用的调试器。 特别是,VS 将在执行finally 之前因未处理的异常而中断,并且不会让您继续。 因此,除非您此时脱离进程,否则您的日志记录代码将永远不会被执行。 换句话说,第二个要求会干扰第一个要求的满足。
Let me recap your requirements the way I understand them:
To meet your first requirement, you should write the code the way everybody suggested - using parameterless catch and throw.
To meet your second requirement while using the parameterless catch, you could configure your debugger to break when an exception is throw, not only when there's an unhandled exception. I suspect you know how to do it, but I'll put it here for answer completeness: in VS you can do that in Debug -> Exception -> Common Language Runtime Exceptions -> check the Thrown checkbox.
If you know that your app throws a lot of handled exceptions, that might not be an option for you. At that point, your only choice left to meet your first requirement is to either write the code to use finally for exception logging purposes or look into the direct IL emitting route as Greg Beech suggests.
However, whether the finally code is being executed depends on the debugger you are using. In particular, VS will break on an unhadled exception before the finally is executed and will not let you continue. Thus, unless you detach from the process at that point, your logging code will never be executed. In other words, the second requirement will interfere with meeting the first requirement.
您可以将逻辑封装在自定义类中,例如:
并将其用作:
希望这会有所帮助。
You could encapsulate your logic in a custom class, something like:
And use it as:
Hope this helps.
您可以在 VB.net 中编写或让别人为您编写一个小程序集,该程序集实现接受四个委托的 TryFaultCatchFinally(of T) 方法:
请注意,执行FaultMethod 时,我们可以在Finally 块破坏导致异常的对象状态之前检查该状态。 执行此操作时必须小心(抛出异常时持有的任何锁将继续持有),但这种能力有时仍然很方便,尤其是在调试时。
我建议例程看起来像这样:
You could write, or have someone write for you, a small assembly in VB.net which implements a TryFaultCatchFinally(of T) method that accepts four delegates:
Note that when the FaultMethod is executed, one may be able to examine the state of objects that caused the exception, before such state is destroyed by Finally blocks. One must use some care when doing this (any locks that were held when the exception was thrown will continue to be held) but the ability may still sometimes be handy, especially when debugging.
I'd suggest the routine look something like:
这不是和: 一样吗
?
Isn't this the same as:
?
不,我认为这是一个常见的习语。
编辑
需要明确的是,“捕获”然后“重新抛出”策略提供相同的运行时语义,但是它们改变了附加 VS 调试器时的体验。 工具和维护很重要; 调试通常要求您“捕获所有第一次机会异常”,如果由于代码中的“catch-then-re throw”而最终导致大量“虚假”第一次机会异常,那么这确实会损害调试代码的能力。 这个惯用语是关于与工具良好交互,以及清楚地表达意图(你不想“捕获”,决定无法处理,然后重新抛出,相反,你只想记录异常确实发生了,但让它就这样过去了)。
No, I think this is a common idiom the way you have it.
EDIT
To be clear, the "catch" then "rethrow" strategies offer the same run-time semantics, however they change the experience when the VS debugger is attached. Tooling and maintenance is important; debugging often requires you to 'catch all first-chance exceptions' and if you end up with lots of 'spurious' first-chance exceptions due to catch-then-rethrow in your code, it really hurts the ability to debug the code. This idiom is about interacting well with the tooling, as well as clearly expressing the intent (you don't want to 'catch', decide can't handle, and rethrow, instead you just want to log that an exception did happen but let it pass on by).
您是否考虑过使用 DebuggerStepThrough 属性?
http://msdn.microsoft.com/en-us/library /system.diagnostics.debuggerstepthroughattribute.aspx
Have you considered using the DebuggerStepThrough attribute?
http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggerstepthroughattribute.aspx
在 C# 6 中添加异常过滤器后,一种选择是使用错误返回异常过滤器,如下所示:
请参阅 https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch 了解更多详细信息异常过滤器。
With exception filters added in C# 6, one option is to make use of a false returning exception filter, like so:
See https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch for more details on exception filters.
因此,在 .NET 中,您所要求的在理论上是可能的,但这并不容易。
CIL 实际上定义了五种类型的异常处理块! 您在 C# 中习惯使用的
try
、catch
和finally
以及另外两个:filter
- 类似于 catch 块,但可以运行任意代码来确定是否要处理错误,而不仅仅是匹配类型。 该块可以访问异常对象,并且对异常堆栈跟踪具有与catch
块相同的效果。fault
- 类似于finally
块,但它仅在发生异常时运行。 该块无权访问异常对象,并且对异常堆栈跟踪没有影响(就像finally
块)。filter
在某些 .NET 语言(例如 VB.NET、C++/CLI)中可用,但遗憾的是在 C# 中不可用。 但是,除了 CIL 之外,我不知道还有什么语言可以表达fault
块。因为它可以在 IL 中完成,但这意味着并非一切都会丢失。 理论上,您可以使用 Reflection.Emit 动态发出一个具有
fault
块的函数,然后将您想要运行的代码作为 lambda 表达式传递(即一个用于 try 部分,一个用于故障)部分,等等),但是(a)这并不容易,并且(b)我不相信这实际上会为您提供比当前获得的更有用的堆栈跟踪。抱歉,答案不是“如何做”类型的事情,但至少现在您知道了! 恕我直言,您现在所做的可能是最好的方法。
请注意,那些说问题中使用的方法是“不好的做法”的人,实际上并非如此。 当您实现
catch
块时,您会说“当异常发生时,我需要对异常对象执行某些操作”,而当您实现finally
时,您会说“我不需要异常对象,但我需要在函数结束之前做一些事情”。如果你实际上想说的是“我不需要异常对象,但我需要在异常发生时做一些事情”,那么你就处于两者之间,即你想要一个
fault< /代码> 块。 由于这在 C# 中不可用,因此您没有理想的选择,因此您也可以选择不太可能因忘记重新抛出而导致错误的选项,并且不会破坏堆栈跟踪。
So, in .NET what you're asking for is theoretically possible, but it's not going to be easy.
CIL actually defines five types of exception handling block! The
try
,catch
andfinally
ones you're used to in C#, and two others:filter
- similar to acatch
block but can run arbitrary code to determine whether it wants to handle the error, rather than just matching on type. This block has access to the exception object, and has the same effect on the exception stack trace as acatch
block.fault
- similar to afinally
block, however it is only run when an exception occurs. This block does not have access to the exception object, and has no effect on the exception stack trace (just like afinally
block).filter
is available in some .NET languages (e.g. VB.NET, C++/CLI) but is not available in C#, unfortunately. However I don't know of any language, other than CIL, that allows thefault
block to be expressed.Because it can be done in IL means not all is lost, though. In theory you could use Reflection.Emit to dynamically emit a function that has a
fault
block and then pass the code you want to run in as lambda expressions (i.e. one for the try part, one for the fault part, and so on), however (a) this isn't easy, and (b) I'm unconvinced that this will actually give you a more useful stack trace than you're currently getting.Sorry the answer isn't a "here's how to do it" type thing, but at least now you know! What you're doing now is probably the best approach IMHO.
Note to those saying that the approach used in the question is 'bad practice', it really isn't. When you implement a
catch
block you're saying "I need to do something with the exception object when an exception occurs" and when you implement afinally
you're saying "I don't need the exception object, but I need to do something before the end of the function".If what you're actually trying to say is "I don't need the exception object, but I need to do something when an exception occurs" then you're half way between the two, i.e. you want a
fault
block. As this isn't available in C#, you don't have an ideal option, so you may as well choose the option that is less likely to cause bugs by forgetting to re-throw, and which doesn't corrupt the stack trace.