3

I maintain an open source library that internally uses exceptions during a recursive method call. The exception is taken back on the call stack and in some cases handled, while in others it will be returned to the caller.

The problem we are having right now is that some users are running Visual Studio Debugger with the "Halt on ALL exceptions" option, so their debugger will halt in our code while it is functioning normally.

Is there any way to prevent that from happening other than telling users to disable that setting? Like, applying some attribute to the code maybe?

Tigraine
  • 23,358
  • 11
  • 65
  • 110

3 Answers3

6

This is very much possible. All you need to do is to get Visual Studio seeing the relevant code as non-user code, and then enable the "Just my code" option in the debugger settings:

enter image description here

There are several ways of convincing Visual Studio that your library is not user code. One is to simply compile a release build without PDB files. Another is to mark your code with DebuggerNonUserCodeAttribute.

There’s a demo project showing this stuff in action: https://bitbucket.org/rstarkov/demononusercode/src – note how the methods in MyLibrary are marked with the non-user-code attribute. Even if you tell Visual Studio to stop on "Thrown" for all exceptions, it will still skip the exception in MyLibrary.

For what it’s worth, I do not consider what you’re doing to be wrong. It’s a question of configuring the debugger properly. Not using any exceptions just because someone has set their debugger to stop on everything does not exactly sound right.

Community
  • 1
  • 1
Roman Starkov
  • 59,298
  • 38
  • 251
  • 324
  • This just flat doesn't work for me. That option is set, I decorated everything in my class that wraps a 3rd party .dll that keeps triggering a break. Now it just breaks on the caller of that code. – dudeNumber4 Aug 06 '12 at 19:21
  • @dudeNumber4 you mean even if the exception was actually caught and handled inside the callee? VS will still stop on unhandled exceptions. Try the example project and see if the exception is skipped in that example. – Roman Starkov Aug 06 '12 at 19:34
  • Note that while the option is also available for C++, it doesn't have an effect on exceptions, as described here: http://msdn.microsoft.com/en-us/library/dn457346.aspx – pjcard Jan 31 '14 at 15:26
2

I don't believe there is any way to prevent "Halt on All Exceptions" from doing exactly that.

Is there any way to prevent that from happening other than telling users to disable that setting?

Only by avoiding using exceptions for non-error handling purposes (from your description, it almost sounds like your library is breaking this guideline).

Richard
  • 106,783
  • 21
  • 203
  • 265
  • 1
    Actually, I believe the guideline is at fault here. The problem here: I'm recursively walking a class dependency tree, and if one dependency down the path can't be satisfied an exception is the only good way to give a good source of the event. The exception may bubble up all the way to the caller, but it can also be handled inside the framework if there is another satisfiable path through the dependency graph. – Tigraine Aug 22 '10 at 11:43
  • And there has to be a way to do that.. I've never seen myself break into Framework code before, and there are quite a few I've used. And ASP.NET for example throws a ThreadAbortException when calling Response.End .. – Tigraine Aug 22 '10 at 11:50
  • @Tigraine: I disagree, a recursive method that bottoms out can return success/fail as well as value. If the branch fails the value contains the details. Consider how you would do it without exceptions and without longjmp (or other non-local goto). – Richard Aug 22 '10 at 13:27
  • @Richard: That would mean wrapping the result in yet another BlaBlaResult object for such a simple case. What about Frameworks like NHibernate that handle underlying SQLExceptions all the time (wrapping them for a rethrow or acting on them). There are use cases where you just wait for the underlying stuff to fail and then do something. – Tigraine Aug 22 '10 at 15:41
  • @Tigraine "it sounds like you're not using this for errors". An error from the DB is exceptional (one doesn't deliberately cause DB errors). If they are genuine errors then exceptions are good. If not (e.g. failed to match down this path, so try another: when that is expected searching behaviour) then exceptions are probably the wrong approach. But it is your code. If you use exceptions and your users want to break on all exceptions in the debugger then they will see a lot of breaks. Your choice, you have to make the trade offs. – Richard Aug 22 '10 at 16:10
  • Thanks for the great input. You definately gave me some ideas. Yet I believe the Java approach where Exceptions are very cheap and more even part of the method signature is better. – Tigraine Aug 22 '10 at 19:46
0

This is a semi-clone of this question.

Note that none of the attributes suggested there seemed to accomplish what you are asking when I them with VS2010.

What you can do, is make sure you're always sending the same custom exception type, ie, TigraineNamespace.TigraineException, then instruct your users to go to the Exceptions dialog (Ctrl+Alt+E), click "Add", write "TigraineNamespace.TigraineException", press Enter, then uncheck the checkbox for your particular exception.

Community
  • 1
  • 1
Omer Raviv
  • 11,409
  • 5
  • 43
  • 82
  • Let's be reasonable here.. Nobody reads the readme anyway and after seeing the 3rd exception they'll just don't bother and use another similar framework :) – Tigraine Aug 26 '10 at 20:08