First, thanks a lot for your comments. Stewart, Robert wrote: <snip>
The idea is interesting, but I see issues of general applicability. For example, there are relatively few circumstances in which one needs to do much of that sort of exception handling. I don't mean to suggest that it doesn't occur, but I wonder if it occurs often enough to warrant a Boost tool.
Another issue is that your approach eliminates access to the calling context. Any handler that needs such access becomes much more complicated. That by no means is required in all circumstances, but it is an issue to consider. I think that in most cases the local context is not required, unless the exception handling is done in a mother-of-all-functions, in which case one could have handlers that are aware of the function's context. (What I mean is that if the local context is needed, then the function is
Well, I think it's all relative. I think that this sort of functionality is useful at the boundaries of logically separate modules. How often you deal with these boundaries depends on what kind of applications you usually work with. In my personal experience I think I needed it 4-5 times. Enough to make me bother trying to generalize it. But you're right, I'm sure that there are tons of developers that didn't see a need for this kind of exception handling. probably big and one could spend some time writing functors that know the function's context). Since the trap_exception syntax is really light-weight, it becomes easy to create traps with different set of handlers. Also, as you point out further down yourself, a lambda function could be used. I think C++0x style lambdas should work jsut fine with trap_exceptions since they are not polymorphic. The only lambdas that can be problematic are polymorphic lambdas, since in that case I won't have access to the type of exception that needs to be caught. But I'm sure there should be a way to supply that type elegantly.
Both of those issues can be addressed by a straightforward, ad hoc macro approach. The common handlers can be assembled in a macro invoked in each function needing them. The preprocessor then inserts the code.
Yeah, I'm aware of the macro approach. But what you lose with the macro approach (not mentioning the fact that you have to deal with them :-) ) is the ability to easily create different traps with different sets of exception handlers. I'm sure that a macro guru could probably replicate trap_exceptions functionality using just macros, but then the solution will become probably a lot more complicated. The straight macros won't take exception types as argument and you'll end up creating different macro for every different set of exceptions.
Is there enough value in your idea to justify a Boost library? Perhaps you'll overcome these issues and prove the value. For example, if trap_exceptions() accepted lambdas, then the calling context would be accessible, at least in C++0x. (Phoenix 3?)
I didn't think myself that it should be a separate library. Perhaps a part of utility? Or another library.
As to the general problem you're solving, my solution has always been this:
extern "C" void f() { try { // do possibly throwing work here } catch (...) { handle_exception(); } }
where handle_exception() looks like this;
void handle_exception() { try { throw; } catch (first_type const & e) { // deal with first_type exception } catch (second_type const & e) { // deal with second_type exception } ... catch (...) { // deal with unrecognized exception } }
Again, it's burdensome to create separate handlers for different sets of exceptions and the developers will tend to write one giant handle-them-all handler. Whereas with trap_exceptions you can just compose them in-place. But I gotta admit that for some reason I really underutilized the approach that you just described. It's not that I wasn't aware of it, but somehow it just never came to my mind when considering this kind of exception handling. Maybe some subconscious aversion to the try/catch syntax? <snip>
The point is there's a lot of room for providing help with exception handling for various purposes, but I'm not certain whether your approach is broadly useful. I'm open to being convinced, however. Well, I hope maybe my reply did the job? :-)
Thanks, Andy.