views:

38

answers:

3

Hi,

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?

+1  A: 

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
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
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
@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
@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
@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
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
A: 

No, you cant prevent it.

I recommend the change your design to use return codes/classes instead of exceptions. Exceptions is very expensive for recursive method calls.

Ertan
A: 

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.

Omer Raviv
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