2

I have some framework / AOP code that logs exceptions from methods called deeper inside...

try {
  ..invoke inner code...
}
catch (Exception e) {
  log(e);
  throw;
}

This works great except for one thing...when my team tries to debug their code in Studio, they only see the exception happening in the logging code (since it gets handled, and then thrown from there).

Is there any way I can get Studio to ignore that my code is catching/throwing an exception...or to inspect the exception on it's way through without catching it?

UPDATE: The issue is that I have framework code that prevents the correct break-point for the real exception from being hit. I am aware that the debugger in visual studio is capable of fine-grained configuration, and I am hoping that someone here can provide a higher level insight than "Learn VS2010 in 31 Hours" does. I simply want to BOTH log the exceptions that are caused in inner code, AND have the break happen at the site of the error WITHOUT turning on 'Break on All Exceptions' which would cause my team to spend 5 minutes pressing the 'Continue' button every time they launched the app (but that's another story).

UPDATE 2: The primary question here, is how can I log the exception, but have the debugger not stop on the 'throw' in my logger, but on the initial exception, without having the debugger stop on all exceptions thrown.

JoshRivers
  • 9,920
  • 8
  • 39
  • 39
  • If you log the exception, why would you want rethrow it for further handling? – Shimmy Weitzhandler May 01 '11 at 06:49
  • Try to examine first chance and second chance exception. – sh_kamalh May 01 '11 at 06:54
  • 1
    @Shimmy: because the exception is valid, and I don't want my application to continue in an invalid state. – JoshRivers May 01 '11 at 08:05
  • @sh_kamalh That's a good lead...is there a mechanism where I can do something like repromote the caught exception for it's second chance? (Since I'm catching it's first?) – JoshRivers May 01 '11 at 08:09
  • @Martinho, you could at least have found a dupe that was somewhat related to my questions, like [1349613](http://stackoverflow.com/questions/1349613/any-way-in-visual-studio-to-not-break-on-throwing-of-a-specific-exception), [418613](http://stackoverflow.com/questions/418613/break-at-throw-for-excption-that-is-caught), [201182](http://stackoverflow.com/questions/201182/debugging-with-exceptions-how-to-work-around-break-when-thrown), or [201504](http://stackoverflow.com/questions/201504/is-it-possible-to-communicate-with-the-visual-studio-debugger-programmatically-wh)...not those are answered. – JoshRivers May 01 '11 at 08:22
  • @Josh: I am sorry about that, but you have to concede that you should have made clear in your question what you had tried, what didn't work and why, just like you showed in your edit. As it was, it was a dupe of the question I linked to. I'm voting to reopen now. – R. Martinho Fernandes May 01 '11 at 08:26
  • By the way, are you using a version of VS2010 with IntelliTrace (aka the Historical Debugger)? That might be helpful here. – R. Martinho Fernandes May 01 '11 at 08:30
  • Thanks @Martinho. And I'm on VS2008, so no joy with IntelliTrace. – JoshRivers May 02 '11 at 04:07

3 Answers3

2

Actually you can make VS break on exceptions. Go to the Debug menu, click exceptions and check both the checkboxes for "Common Language Runtime Exceptions". Now you'll get a debug break at the point the exception is thrown.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • Thanks for answering. I need a more subtle solution. – JoshRivers May 01 '11 at 08:10
  • @Josh: Please explain more clearly what is wrong with this solution. – Brian May 02 '11 at 13:33
  • @Brian, given that he comes from an AOP framework, I'm assuming he wants a way to automatically tack some code to certain exceptions being thrown. Unfortunately this solution is all I have. – Blindy May 02 '11 at 13:40
1

I've done some digging, and the answer in 1349613 put me on a good scent. I've added the attribute:

[DebuggerNonUserCode]

To my logging class. Now when the internal, invoked code throws an exception, the debugger ignores the logging code, and it's Try/Catch block, and goes straight to the internal exception.

Community
  • 1
  • 1
JoshRivers
  • 9,920
  • 8
  • 39
  • 39
0

It is possible in VB.NET to examine an exception without catching it, and before any stack unwinding has occurred as a consequence of it. While it is generally dangerous to do very much between the time the exception has been thrown and the time the stack has been unwound, one may capture the exception and then make use of it in a finally block. One might also set a flag or other indicator to let stack-unwinding code know where the exception is going to be caught. Unfortunately, the usefulness of the latter ability is limited because of a (largely language-forced) anti-pattern of code catching exceptions that it needs to react to, but that can't expect to resolve. For example, if an exception is thrown in a constructor after it has created some IDisposable objects and stored them in fields, the constructor has to react to the exception by cleaning up the fields it has created, but has no hope of resolving the situation and returning normally. If a constructor might have multiple return points, it would be semantically cleaner of one could say:

try
{
  ... create IDisposables
}
finally(Exception ex)
{
  if (ex != null)
    this.Dispose();
}

than having to say

try
{
  ... create IDisposables
}
catch(Exception ex)
{
  this.Dispose();
  throw ex;
}

since the former would avoid catching an exception it had no expectation of handling. One could write a wrapper method in VB that would accept a pair of delegates and implement the second using the same semantics as the finally(Exception ex) above would have, but unfortunately C# provides no such facility itself.

supercat
  • 77,689
  • 9
  • 166
  • 211