[review] Review of Exception begins today
The formal review of the Exception library, proposed by Emil Dotchevski, begins today. The library provides an exception class that can transport arbitrary values, thus freeing the user from designing custom exception classes. The library can be downloaded at http://tinyurl.com/24wtwu and its documentation can be read online at http://tinyurl.com/2bkojl . What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. We're looking forward to your evaluation of this Boost candidate! Tobias Schwinger - Review Manager -
The library provides an exception class that can transport arbitrary values, thus freeing the user from designing custom exception classes.
I should clarify that the purpose of the library is not to free users from writing custom exception classes: after all, exceptions are caught by type -- not by value -- so to be able to tell one failure from another, we need to throw different types. The idea behind the proposed exception library is to move the burden of storing error codes, file names and other data relevant to a given failure, from the individual exception classes, to a single base class. This way the exception class hierarchy can be implemented entirely in terms of empty classes while still being able to transport to the catch site whatever information is necessary to handle a particular exception. Emil Dotchevski
The library provides the macro BOOST_ERROR_INFO. Is it possible to modify the macro in such a way that successive calls of BOOST_ERROR_INFO would add the date in a list? This could be used in order to get infos which parts of the code catched the exception. Regards, oliver
The library provides an exception class that can transport arbitrary values, thus freeing the user from designing custom exception classes.
I should clarify that the purpose of the library is not to free users from writing custom exception classes: after all, exceptions are caught by type -- not by value -- so to be able to tell one failure from another, we need to throw different types.
The idea behind the proposed exception library is to move the burden of storing error codes, file names and other data relevant to a given failure, from the individual exception classes, to a single base class.
This way the exception class hierarchy can be implemented entirely in terms of empty classes while still being able to transport to the catch site whatever information is necessary to handle a particular exception.
Emil Dotchevski _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The library provides the macro BOOST_ERROR_INFO. Is it possible to modify the macro in such a way that successive calls of BOOST_ERROR_INFO would add the date in a list? This could be used in order to get infos which parts of the code catched the exception.
Yes, I guess that's possible, but I think that what contexts catch (add BOOST_ERROR_INFO) and rethrow is less useful information than, for example, the caller stack at the time the exception was first thrown -- which is the type of info BOOST_ERROR_INFO is designed to stuff in exceptions. OTOH, if there is a way to detect a catch _automagically_, I suppose recording each catch in the exception object would be a good thing. Emil Dotchevski
* What is your evaluation of the design?
I'm not keen on the use of operator<< to add the data to the exceptions. << has two existing meanings, left-shift and formatted output. Note that the standard library does not use << for operations like push_back() and insert(). Adding another meaning here is not helpful. For example, it's common for exceptions to have human-readable formatted content. A user seeing code that uses operator<< on an exception might easily imagine that this is doing formatted output, and think "cool! I can do formatted output to this exception!", and write: catch (some_exception& E) { E << " while frobinacting at warp level " << warp_level; throw; } Of course this isn't going to work. If your code used a more conventional syntax, e.g. E.add_info<errno_tag>(errno); then this confusion would be avoided. (And I think it could be more concise too.) Is "exception" the best choice of name for this library? The name boost::exception might give the impression that it's the base class for all Boost exceptions, which is not the case; I might accidentlally write catch (boost::exception& E) { cerr << "got an exception from Boost: ....."; Also, there's the possibility that someone might propose some other exception-related library, orthogonal to this one, in the future. How about "tagged_exception"?
* What is your evaluation of the implementation?
I haven't looked at the code.
* What is your evaluation of the documentation?
Good. You might like to say something about the overhead that is added, i.e. that there is a std::list<something> in each exception (or whatever). (Remember that there are still plenty of people who dislike exceptions because of the perceived overhead that they involve.) I think you do say something about the exception guarantee, but it might be useful to add a more explicit section near the start describing the exception guarantee and also whether any dynamic memory allocation is involved; what happens if the exception that was thrown was "out of memory"?
* Did you try to use the library? With what compiler?
No.
* How much effort did you put into your evaluation?
About an hour reading the docs and preparing this message.
* Are you knowledgeable about the problem domain?
I have previously considered the problem of storing errno and a filename in an exception and have my own non-generic solution.
* Do you think the library should be accepted as a Boost library?
Only if operator<< is replaced. Regards, Phil.
On 9/30/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
* What is your evaluation of the design?
I'm not keen on the use of operator<< to add the data to the exceptions.
I share Phil's criticism about operator<<. [snip]
Regards,
Phil.
Still trying to find time to properly review the library, Best regards, -- Felipe Magno de Almeida
From: Phil Endecott I'm not keen on the use of operator<< to add the data to the exceptions. [...] If your code used a more conventional syntax, e.g.
E.add_info<errno_tag>(errno);
Sounds like a good idea to me too. It could both simplify the interface (no boost::error_info class and the << operator, just one template member function) and make throw expressions shorter. This would also resolve the ambiguity mentioned by Phil. The boost::get_error_info could also be a member function for consistency, so you would get: try { try { throw my_error().add_info<tag_errno>(errno).add_info<tag_foo>(foo); } catch( boost::exception & x ) { x.add_info<tag_file_name>(file_name); throw; } } catch( my_error & x ) { if( int const * errnum = x.get_info<tag_errno>() ) std::cerr << "Error code: " << (*errnum); } Best regards, Robert
I'm not keen on the use of operator<< to add the data to the exceptions.
I do share your concern, but consider that whatever we use for boost exception should support easy composition, because it needs to work when used in a throw expression directly: throw my_error() << error_info<tag_errno>(errno) << error_info<tag_name>(name); Instead of << we could use .add: throw my_error(). add(error_info<tag_errno>(errno)). add(error_info<tag_name>(name)); This isn't bad, but in my opinion the << syntax is better despite my strong dislike for operator overloading.
<snip> catch (some_exception& E) { E << " while frobinacting at warp level " << warp_level; throw; }
Of course this isn't going to work.
Right, it's not going to compile.
Is "exception" the best choice of name for this library? The name boost::exception might give the impression that it's the base class for all Boost exceptions, which is not the case;
In my ideal world, the functionality of boost::exception would be implemented directly by std::exception ;) That said, there is an easy way to make boost::exception the base of all exception emitted by boost: #ifdef BOOST_NO_EXCEPTIONS namespace boost { void throw_exception(std::exception const & e); // user defined } #else #include <boost/exception.hpp> namespace boost { template<class E> void throw_exception(E const & e) { throw enable_error_info(e); //see documentation } } #endif (I'm now thinking we need to add some trickery to enable_error_info, so it does not inject boost::exception as a base if it is a base already.) This adds very little overhead to all exceptions: an empty shared_ptr, which does not allocate any memory. The benefit is that now user code can catch any boost exception as a boost::exception, and add application-specific error information to exceptions coming from boost libraries: try { ---use boost--- } catch( boost::exception & x ) { x << error_info<my_info>(.....); throw; }
Also, there's the possibility that someone might propose some other exception-related library, orthogonal to this one, in the future. How about "tagged_exception"?
I think there is a lot of value to enabling all exceptions to carry arbitrary failure-related information. The main motivation for Boost Exception is that a library that throws an exception can not possibly anticipate everything that is relevant to that type of failure in a particular client application. I think that even if a particular library has no info to add to an exception, it should throw exceptions that derive from Boost Exception, even if it's just to enable information to be added later on. If you agree with the above, I think you'd agree that boost::exception is the appropriate name to use. That said, I am very much interested all negative feedback. Do you see any reasons why you wouldn't want to use Boost Exception as a base for all of your exceptions? Do you think the current design of Boost Exception can be improved so it better serves its intended design goal as universal base class that can transport arbitrary failure-related data to the catch site?
You might like to say something about the overhead that is added, i.e. that there is a std::list<something> in each exception (or whatever). (Remember that there are still plenty of people who dislike exceptions because of the perceived overhead that they involve.)
In this particular library we shouldn't be concerned with people who don't like exceptions because of the exception handling overhead itself. As for the additional overhead of Boost Exception, the price you pay if you don't add any info to it is an empty shared_ptr. If you do add info, then more memory is allocated -- however notice that all of that memory is allocated only when throwing exception, and that it is freed when the exception is handled. I can't imagine a use case when that would cause any issues.
I think you do say something about the exception guarantee, but it might be useful to add a more explicit section near the start describing the exception guarantee and also whether any dynamic memory allocation is involved; what happens if the exception that was thrown was "out of memory"?
That's in the FAQ already. :) Emil Dotchevski
Emil Dotchevski wrote:
I'm not keen on the use of operator<< to add the data to the exceptions.
I do share your concern, but consider that whatever we use for boost exception should support easy composition, because it needs to work when used in a throw expression directly:
throw my_error() << error_info<tag_errno>(errno) << error_info<tag_name>(name);
Instead of << we could use .add:
throw my_error(). add(error_info<tag_errno>(errno)). add(error_info<tag_name>(name));
This isn't bad, but in my opinion the << syntax is better despite my strong dislike for operator overloading.
Maybe a more or less obvious choice will do throw my_error() = error_info<tag>(whatever), error_info<another_tag>(something_else) // ... Regards, Tobias Schwinger - Review Manager -
I'm not keen on the use of operator<< to add the data to the exceptions.
I do share your concern, but consider that whatever we use for boost exception should support easy composition, because it needs to work when used in a throw expression directly:
throw my_error() << error_info<tag_errno>(errno) << error_info<tag_name>(name);
Instead of << we could use .add:
throw my_error(). add(error_info<tag_errno>(errno)). add(error_info<tag_name>(name));
This isn't bad, but in my opinion the << syntax is better despite my strong dislike for operator overloading.
Maybe a more or less obvious choice will do
throw my_error() = error_info<tag>(whatever), error_info<another_tag>(something_else) // ...
I don't know, I'd rather use .add(), to be honest. Also, in an off-list discussion, Peter Dimov pointed out that instead of layering .add calls directly in the throw expression, we could write: my_error tmp; tmp.add(error_info<tag_errno>(errno)); tmp.add(error_info<tag_name>(name)); throw tmp; I'm not strongly opposed to that either. Anyway, I think that operator<< is a good compromise, but if others feel strongly against it I'll happily change it to .add(). Emil Dotchevski
Tobias Schwinger wrote:
Emil Dotchevski wrote:
I'm not keen on the use of operator<< to add the data to the exceptions. I do share your concern, but consider that whatever we use for boost exception should support easy composition, because it needs to work when used in a throw expression directly:
throw my_error() << error_info<tag_errno>(errno) << error_info<tag_name>(name);
Instead of << we could use .add:
throw my_error(). add(error_info<tag_errno>(errno)). add(error_info<tag_name>(name));
This isn't bad, but in my opinion the << syntax is better despite my strong dislike for operator overloading.
Maybe a more or less obvious choice will do
throw my_error() = error_info<tag>(whatever), error_info<another_tag>(something_else) // ...
Forgot to say: See Boost.Assign. Making 'add' a function template might be another alternative: throw my_error() .add<tag::errno>(errno) .add<tag::name>(name) // ... Regards, Tobias Schwinger - Review Manager -
<snip> Making 'add' a function template might be another alternative:
throw my_error() .add<tag::errno>(errno) .add<tag::name>(name) // ...
Right, this syntax look better than my "add". If there is a consensus that the operator<< overload should be removed, I'd be voting for the syntax above. Emil Dotchevski
Tobias Schwinger <tschwinger <at> isonews2.com> writes:
Emil Dotchevski wrote:
I'm not keen on the use of operator<< to add the data to the exceptions.
I do share your concern, but consider that whatever we use for boost exception should support easy composition, because it needs to work when used in a throw expression directly:
throw my_error() << error_info<tag_errno>(errno) << error_info<tag_name>(name);
Instead of << we could use .add:
throw my_error(). add(error_info<tag_errno>(errno)). add(error_info<tag_name>(name));
This isn't bad, but in my opinion the << syntax is better despite my strong dislike for operator overloading.
Maybe a more or less obvious choice will do
throw my_error() = error_info<tag>(whatever), error_info<another_tag>(something_else) // ...
Why not use approach similar (if not based upon) named function parameters: throw my_error().data(( tag_errno = errno, tag_name = name, .... )) or for exception classes with trivial forwarding temaplte constructor throw my_error(( tag_errno = errno, tag_name = name, .... )) I also strongly in favor boost::optional instead of pointer result type. Gennadiy
Why not use approach similar (if not based upon) named function parameters:
throw my_error().data(( tag_errno = errno, tag_name = name, .... ))
That's not bad at all, and seems totally possible. Thanks for the suggestion.
I also strongly in favor boost::optional instead of pointer result type.
What is the problem with the pointer? Emil Dotchevski
Emil Dotchevski <emil <at> revergestudios.com> writes:
Why not use approach similar (if not based upon) named function parameters:
throw my_error().data(( tag_errno = errno, tag_name = name, .... ))
That's not bad at all, and seems totally possible. Thanks for the suggestion.
I also strongly in favor boost::optional instead of pointer result type.
What is the problem with the pointer?
It's pointer ;) Optional more clearly indicate your intention and safer. Gennadiy
on Sun Sep 30 2007, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception," the only relationship being that C++ exceptions are involved. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception," the only relationship being that C++ exceptions are involved.
Do you mean the name of the library or the name of the defined class exception? If you mean the name of the library, I don't mind calling it something else. If you mean the name of the class, then I'm interested to hear what are the several other things that you'd like class exception to support. Emil Dotchevski
on Tue Oct 02 2007, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception," the only relationship being that C++ exceptions are involved.
Do you mean the name of the library or the name of the defined class exception?
I meant the library. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Wouldn't it make sense to combine boost:exception and boost:system (at least error_code and error_category stuff)? I find the error_code concept not only useful for system errors. Oliver
on Tue Oct 02 2007, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception," the only relationship being that C++ exceptions are involved.
Do you mean the name of the library or the name of the defined class exception?
I meant the library.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Wouldn't it make sense to combine boost:exception and boost:system (at least error_code and error_category stuff)? I find the error_code concept not only useful for system errors. Oliver
Are you proposing to define error_code and error_category tags as part of the Boost Exception library? Emil Dotchevski
Wouldn't it make sense to combine boost:exception and boost:system (at least error_code and error_category stuff)? I find the error_code concept not only useful for system errors. Oliver
Are you proposing to define error_code and error_category tags as part of the Boost Exception library?
Yes - because it's related to error/exception passing. I'm using both libs in my projects. Oliver
Wouldn't it make sense to combine boost:exception and boost:system (at least error_code and error_category stuff)? I find the error_code concept not only useful for system errors. Oliver
Are you proposing to define error_code and error_category tags as part of the Boost Exception library?
Yes - because it's related to error/exception passing. I'm using both libs in my projects.
As a user of both libs, what do you think is more appropriate: - To have error_category and error_code tags in Boost Exception, or - To use separate Boost Exception tags for each category, each tag identifying an integer error code? Emil Dotchevski
Wouldn't it make sense to combine boost:exception and boost:system (at least error_code and error_category stuff)? I find the error_code concept not only useful for system errors. Oliver
Are you proposing to define error_code and error_category tags as part of the Boost Exception library?
Yes - because it's related to error/exception passing. I'm using both libs in my projects.
As a user of both libs, what do you think is more appropriate:
- To have error_category and error_code tags in Boost Exception, or
- To use separate Boost Exception tags for each category, each tag identifying an integer error code?
Hmmm - my code looks like this: throw some_error() << BOOST_ERROR_INFO << boost::error_info< tag_error_code >( boost::system::error_code( errno, boost::system::errno_ec) ); I think there is no need for extra tags for error_code and error_category. I suggest that both classes and your exception framework should be in one boost library. Oliver
Hmmm - my code looks like this:
throw some_error() << BOOST_ERROR_INFO << boost::error_info< tag_error_code >( boost::system::error_code( errno, boost::system::errno_ec) );
As far as I know the point of the error category in boost::system is to classify the error code, so that error codes (integers) returned from different systems can coexist. I think that with boost exception, a better way to differentiate one integer (error code) from another is to just use different tags. In other words, instead of the code above, you'd have: throw some_error() << BOOST_ERROR_INFO << boost::error_info<tag_errno>(errno); where struct tag_errno: boost::error_info_value<int> { }; Emil Dotchevski
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception," the only relationship being that C++ exceptions are involved.
One such thing might be rethrow functionality. class exception { void rethrow() const throw (exception) = 0; // { throw cloneException(); } }; Such functionality can be used to try {} and catch {} in separate threads. In fact, I can recall at least one library in boost vault (join) that requires such functionality already. Chris Knight FuturePath Trading, LLC cknight@fptrading.net _________________________________________________________________ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
On 2007-10-03, David Abrahams <dave@boost-consulting.com> wrote:
on Sun Sep 30 2007, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name.
This was my main concern with the library, as well. As it stands, the library consists primarily of a method for attaching data to objects at runtime. This is a neat, well-thought-out capability that I can imagine would be useful outside the realm of exceptions. If this library were renamed (though a really good name isn't coming to mind right now), it could of course still be used in any future boost exception lib. -- Austin Bingham
David Abrahams wrote:
on Sun Sep 30 2007, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
Is "exception" the best choice of name for this library?
I think the functionality of this library may be too specific to be given such a general name. There are several other things one might want to do in a library called "exception,"
...such as? Besides satisfying my own curiosity, the wider scope of a library that qualifies for the name "Exception" would still be interesting in the context of this review. Regards, Tobias Schwinger - Review Manager -
Tobias Schwinger wrote:
...such as?
Besides satisfying my own curiosity, the wider scope of a library that qualifies for the name "Exception" would still be interesting in the context of this review.
Asynchronous exception handling: // rethrow/clone concepts class exception { virtual void rethrow() const = 0; virtual exception* clone() const = 0; }; template<typename T> class build_rethrowable_exception { void rethrow() const { throw T(*this); } exception* clone() const { return new T(*this); } }; // user defined exception class my_exception : public build_rethrowable_exception<my_exception> { }; // example of asynchronous exception handling class queue_item_visitor : public boost::static_visitor<> { void operator()(const exception& ex) { ex.rethrow(); } void operator()(const message& msg) { ... } }; typedef boost::shared_ptr<exception> exception_ptr; typedef boost::shared_ptr<message> message_ptr; typedef boost::variant<exception_ptr, message_ptr> queue_item; typedef boost::shared_ptr<queue_item> queue_item_ptr; TSQueue<queue_item_ptr> s_queue; thread1: // some thread responsible for reading messages { while (...) { try { s_queue.push_back(queue_item_ptr(new queue_item(read_message()))); } catch (const exception& ex) { s_queue.push_back(queue_item_ptr(new queue_item(exception_ptr(ex.clone())))); } } } thread2: // some thread responsible for processing messages { while (...) { queue_item_ptr item(s_queue.pop_front()); boost::apply_visitor(queue_item_visitor(), *item); } } _________________________________________________________________ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
Chris Knight wrote:
Tobias Schwinger wrote:
...such as?
Besides satisfying my own curiosity, the wider scope of a library that qualifies for the name "Exception" would still be interesting in the context of this review.
Asynchronous exception handling:
<code> Thanks, Chris! Seems a generic exception base class (such as the one being reviewed) probably /should/ provide those member functions... Where are the domain experts complaining about missing functionality?! Please send in your reviews! Regards, Tobias Schwinger - Review Manager -
Tobias Schwinger:
Where are the domain experts complaining about missing functionality?!
Busy getting the functionality into C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html
There is also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html. Emil Dotchevski
On Thu, 2007-09-27 at 17:43 -0400, Tobias Schwinger wrote:
The formal review of the Exception library, proposed by Emil Dotchevski, begins today.
The library provides an exception class that can transport arbitrary values, thus freeing the user from designing custom exception classes.
Here's my review of the proposed Exception library; apologies for not being in the "standard" format. I'm just now reading through the other Exception review feedback, so some of my concerns and questions may already have been addressed... ==== My over-all impression of the Exception library is very favorable. It provides an elegant solution to the problem of collecting "supporting details" in generic fashion as an exception propagates; it would be immediately useful to us. My evaluation consisted of a detailed reading of the documentation and a casual inspection of the code. Some areas of concern and specific suggestions: Thread safety. The documentation does not specify what guarantees (or lack there of) the library makes about threading or re-entrancy. I think this is crucial for a library like Exceptions. I think a reasonable level of thread-safety would be to support the concurrent creation/throwing/catching/manipulating distinct instances of boost::exception from multiple threads. Identifier registration should also be thread-safe. Concurrent operations on a single instance of boost::exception need not be thread safe. On my casual inspection of the code, I did not see anything which would preclude supporting such a guarantee. Introspection. boost::error_info<> allows me to extract a specific piece of data presuming I know the corresponding identifier. boost::exception::what() has some support for enumerating all of the contained values in a generic manner. I would like to have an explicit interface which I could use to enumerate the values contained within a boost::exception without prior knowledge of their types. Some sort of iterator-style interface, perhaps leveraging boost::any to return the values, for example. Duplicate identifiers. It was not clear from reading the documentation what the behavior of the Exception library is when an attempt is made to store a value into boost::exception using an identifier for which a value already exists. Reading the code reveals that the original value will be silently overwritten. It might be beneficial to have a richer API here, perhaps with "checked" and "unchecked" insertion to allow clients to catch cases where a value will be overwritten. std::exception. I think the rationale for not deriving from std::exception is sound, but it's worth pointing out that the concerns about duplicate std::exception instances could be resolved by having boost::exception derive from std::exception using virtual inheritance. Support for polymorphic cloning/rethrowing. We often have the need to clone and rethrow polymorphic exceptions; this is useful, for example, to "transport" exceptions from one thread to another. There are a number of competing proposals before the ANSI C++ standards committee in this area, including N2229, "Cloning and Throwing Dynamically Typed Exceptions" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2229.html). It would be nice to see some level of support for this sort of functionality in the Exceptions library. Chaining. Sometimes there is a need to catch one exception type and throw a new type instead; this can often happen at the boundaries between different libraries, for example. Though a new exception type must be thrown, you'd rather not lose the information contained in the original exception: this can be captured by chaining the exceptions together. "This exception was caused by that exception." Chaining can certainly be expressed with the proposed Exception library by creating the appropriate identifier and storing the root cause inside the new exception. But I'd be interested in some discussion about explicit support for chaining. -Chris
participants (12)
-
Austin Bingham -
Chris Knight -
Chris Newbold -
David Abrahams -
Emil Dotchevski -
Felipe Magno de Almeida -
Gennadiy Rozental -
Oliver.Kowalke＠qimonda.com -
Peter Dimov -
Phil Endecott -
Robert Kawulak -
Tobias Schwinger