Review Request: Boost Exception
I believe the proposed Boost Exception library is now mature enough for formal review. Please read the documentation at: http://www.revergestudios.com/boost-exception/boost-exception.htm Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8: http://www.revergestudios.com/boost-exception/boost-exception.zip Regards, Emil Dotchevski
"Emil Dotchevski" <emildotchevski@hotmail.com> writes:
I believe the proposed Boost Exception library is now mature enough for formal review.
Please read the documentation at:
http://www.revergestudios.com/boost-exception/boost-exception.htm
The introduction reveals some problems 1. The first sentence is very confusing and gives the strong impression of being completely circular. "The main motivation for using exception handling is that when writing exception-safe code, the vast majority of contexts in the program are exception-neutral." That's like saying, "the main motivation for using a hammer is that, when hammering, the vast majority of contexts require driving a nail." 2. The second sentence begins with "But." Although gaining currency, mostly for informal writing, that's still not considered correct in most circles. 3. "The semantics of exception handling suggest throwing unnamed temporary objects,..." They do? How so? "...therefore, the throw site needs to have all the information relevant to the failure" The 2nd part doesn't follow from the first part. 4. In the 3rd paragraph, "which" should be "that" Finally, in the 3rd paragraph, you tell me what this library does. That part makes sense. I suggest you: * figure out what you mean to say in the introduction * write it first as a series of terse bullets * do not attempt to give background about EH in general Then you can translate these bullets into prose. The introduction will probably end up being just a few sentences long. The first example uses "error_info_value" without qualification. You need to test your examples. If you write your documentation using ReStructuredText, you can use the system we use for the parameter library, in tools/litre. No comparable system exists for boostbook today; you'll have to build one or test the examples by hand. Finally, a design note: I don't like the fact that I need a try/catch block in order to adorn the currently-unwinding exception with more information; it's just too heavy syntactically. I realize it would require TLS for thread-safety, but I'd like to see an option that uses the destructor of a local object to do the same work. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Finally, a design note: I don't like the fact that I need a try/catch block in order to adorn the currently-unwinding exception with more information; it's just too heavy syntactically. I realize it would require TLS for thread-safety, but I'd like to see an option that uses the destructor of a local object to do the same work.
It isn't clear how do you think this should work. Your TLS remark implies that the information would be stored separately from the exception object itself, but as you very well know, more than one exception can be active at a time. Moving the catch clause to a destructor doesn't seem an improvement to me.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Finally, a design note: I don't like the fact that I need a try/catch block in order to adorn the currently-unwinding exception with more information; it's just too heavy syntactically. I realize it would require TLS for thread-safety, but I'd like to see an option that uses the destructor of a local object to do the same work.
It isn't clear how do you think this should work. Your TLS remark implies that the information would be stored separately from the exception object itself, but as you very well know, more than one exception can be active at a time.
Yep, you'd need a stack.
Moving the catch clause to a destructor doesn't seem an improvement to me.
Using a catch clause to add information to a propagating exception feels syntactically heavy to me, but of course others may disagree. And it may also be that without language support, there's not really a good way to avoid that weight. I'm just expressing an aesthetic preference here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Moving the catch clause to a destructor doesn't seem an improvement to me.
Using a catch clause to add information to a propagating exception feels syntactically heavy to me, but of course others may disagree. And it may also be that without language support, there's not really a good way to avoid that weight. I'm just expressing an aesthetic preference here.
Won't you need to prepare all the extra information even if nothing throws?
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Moving the catch clause to a destructor doesn't seem an improvement to me.
Using a catch clause to add information to a propagating exception feels syntactically heavy to me, but of course others may disagree. And it may also be that without language support, there's not really a good way to avoid that weight. I'm just expressing an aesthetic preference here.
Won't you need to prepare all the extra information even if nothing throws?
No, you could do it lazily. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Moving the catch clause to a destructor doesn't seem an improvement to me.
Using a catch clause to add information to a propagating exception feels syntactically heavy to me, but of course others may disagree. And it may also be that without language support, there's not really a good way to avoid that weight. I'm just expressing an aesthetic preference here.
Won't you need to prepare all the extra information even if nothing throws?
No, you could do it lazily.
I'm afraid that I need to be shown an example in order to "get it". :-)
David Abrahams wrote:
The first example uses "error_info_value" without qualification. You need to test your examples.
In the examples in the documentation, only "exception" is qualified, to differentiate between boost::exception and std::exception. The examples are easier to read and understand without boost:: sprinkled all over. As for testing, I tried to compile the first example, the compiler choked on the "...." and I gave up. :)
Finally, a design note: I don't like the fact that I need a try/catch block in order to adorn the currently-unwinding exception with more information; it's just too heavy syntactically. I realize it would require TLS for thread-safety, but I'd like to see an option that uses the destructor of a local object to do the same work.
I realize that try...catch is a heavy thing to type. I also realize that the whole point of being exception-neutral is to not have to catch (there I go again, circular logic), however if you use a local object's destructor to do the work, you have to stuff the extra error_infos in that local object even if no exception is thrown. I'm not convinced that this overhead is insignificant. Emil Dotchevski
"Emil Dotchevski" <emildotchevski@hotmail.com> writes:
David Abrahams wrote:
The first example uses "error_info_value" without qualification. You need to test your examples.
In the examples in the documentation, only "exception" is qualified, to differentiate between boost::exception and std::exception. The examples are easier to read and understand without boost:: sprinkled all over.
In my opinion they're not. I think the idea that leaving out qualification clarifies code is a common misconception.
As for testing, I tried to compile the first example, the compiler choked on the "...." and I gave up. :)
??! -- Dave Abrahams Boost Consulting www.boost-consulting.com
I believe the proposed Boost Exception library is now mature enough for formal review.
Please read the documentation at:
http://www.revergestudios.com/boost-exception/boost-exception.htm
There are several problems with the docs linked above, besides those that Dave Abrahams has already pointed out. Did the code and online docs just get out of sync somehow? The enable_error_info function template is referred to as a class when it is initially introduced: "This is accomplished by the enable_error_info class template. Here is an example:" T must not be a reference in error_info_value<T>, because that would introduce references to references in various places. This should be documented, or fixed using a reference type specialization and boost::ref. boost::exception's constructors and destructor are in its online docs, but are not part of its public interface. The actual signature of error_info type is: template <class Name,class T> typename error_info_type<Name>::type const * get_error_info( T const & ); but the online docs list it as this: template <class Name,class T> typename error_info_type<Name>::type get_error_info( T const & some_exception ); The tag struct declarations in the first example are missing semicolons. It would be nice to have the actual headers linked to somewhere in the online docs.
Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8:
http://www.revergestudios.com/boost-exception/boost-exception.zip
As for the library itself, the name "exception" is fine within the context of Boost, but it's going to collide with std::exception if this is ever standardized. Is there another name for this? I have to admit, nothing better springs to mind. I think enable_error_info be called make_exception or make_error_info (or make_[whatever]), in keeping with all the standard and Boost make_*<> function templates. What is the motivation for the Logging system's string conversion behavior #3? It seems that a compilation failure would be preferable in most cases, since the silent failure of #3 to convert to a string won't be noticed until the program is completely compiled and executed. I'd rather know at compile time. This should at least be an option. Overall, I think this library looks very useful. I'd like to see the above things improved, but I'd really like to see this make it into Boost. Zach Laine
Zach Laine wrote:
I believe the proposed Boost Exception library is now mature enough for formal review.
Please read the documentation at:
http://www.revergestudios.com/boost-exception/boost-exception.htm
There are several problems with the docs linked above, besides those that Dave Abrahams has already pointed out. Did the code and online docs just get out of sync somehow?
Most of the issues you point out are indeed errors in the documentation.
The enable_error_info function template is referred to as a class when it is initially introduced: "This is accomplished by the enable_error_info class template. Here is an example:"
Fixed.
T must not be a reference in error_info_value<T>, because that would introduce references to references in various places. This should be documented, or fixed using a reference type specialization and boost::ref.
Modified the documentation to point out that T must not be a reference.
boost::exception's constructors and destructor are in its online docs, but are not part of its public interface.
This was by design. The constructors and the destructor are documented and are part of class exception's protected interface.
The actual signature of error_info type is:
template <class Name,class T> typename error_info_type<Name>::type const * get_error_info( T const & );
but the online docs list it as this:
<snip>
Fixed.
The tag struct declarations in the first example are missing semicolons.
If you're talking about this example: http://www.revergestudios.com/boost-exception/boost-exception.htm#basic_usag... I did not modify it, it had the semicolons.
It would be nice to have the actual headers linked to somewhere in the online docs.
Done. You can browse the source code, tests and everything here: http://www.revergestudios.com/boost-exception/src/
As for the library itself, the name "exception" is fine within the context of Boost, but it's going to collide with std::exception if this is ever standardized. Is there another name for this? I have to admit, nothing better springs to mind.
Since you bring it up, please do correct me if I'm wrong but *if* this is ever standardized, it could expand the semantics of std::exception. As far as I can see, this would not break existing code because the boost::exception constructors don't allocate memory and don't throw exceptions. Besides a pointer to the internal implementation (which is the only data member of boost::exception) there is no overhead; I could not find anything in 18.6.1 that boost::exception would violate.
I think enable_error_info be called make_exception or make_error_info (or make_[whatever]), in keeping with all the standard and Boost make_*<> function templates.
It shouldn't be make_error_info because that's not what it makes, it makes a boost::exception. I think that enable_error_info is more accurate than make_exception (English is not my native language).
What is the motivation for the Logging system's string conversion behavior #3? It seems that a compilation failure would be preferable in most cases, since the silent failure of #3 to convert to a string won't be noticed until the program is completely compiled and executed. I'd rather know at compile time. This should at least be an option.
You can store any value in a boost::exception even if it can't convert to a string. For example, as I've done in the example at the end of the documentation, you can add a boost::weak_ptr<FILE> object in a boost::exception. It isn't reasonable to require the user to define a to_string overload for boost::weak_ptr, just to be able to store it in a boost::exception. Besides, even if you do require a to_string overload for boost::weak_ptr, that overload can only return something generic like "<weak_ptr>", which is similar to what you get from the fallback behavior of what() anyway. In general, the value you store in a boost::exception could be something you can't print, but can be used to get you the thing you can print; this is beyond the scope of what().
<snip>
boost::exception's constructors and destructor are in its online docs, but are not part of its public interface.
This was by design. The constructors and the destructor are documented and are part of class exception's protected interface.
Fair enough.
The tag struct declarations in the first example are missing semicolons.
If you're talking about this example:
http://www.revergestudios.com/boost-exception/boost-exception.htm#basic_usag...
I did not modify it, it had the semicolons.
Sorry, I meant to say the first example in "Frequently Asked Questions". Those are missing the semicolons. In general, I think it will be easier for you if you take working, compiled code, and cut out the pieces you want to include in your docs, so that you know everything in the docs at least compiles.
It would be nice to have the actual headers linked to somewhere in the online docs.
Done. You can browse the source code, tests and everything here:
I actually meant that the online docs that you intend to submit for review would benefit from having the library's source files included as well.
As for the library itself, the name "exception" is fine within the context of Boost, but it's going to collide with std::exception if this is ever standardized. Is there another name for this? I have to admit, nothing better springs to mind.
Since you bring it up, please do correct me if I'm wrong but *if* this is ever standardized, it could expand the semantics of std::exception. As far as I can see, this would not break existing code because the boost::exception constructors don't allocate memory and don't throw exceptions. Besides a pointer to the internal implementation (which is the only data member of boost::exception) there is no overhead; I could not find anything in 18.6.1 that boost::exception would violate.
That's correct, but I think a likelier scenario for standardization would be to include Boost.Exception as-is, so that it a) does not affect any current standard library or user code, and b) retains its full usefulness (I'm thinking here of your rationale section "Why doesn't boost::exception derive from std::exception?"). Anyway, this isn't a major objection, just something to think about.
I think enable_error_info be called make_exception or make_error_info (or make_[whatever]), in keeping with all the standard and Boost make_*<> function templates.
It shouldn't be make_error_info because that's not what it makes, it makes a boost::exception. I think that enable_error_info is more accurate than make_exception (English is not my native language).
Alright, then it sounds like if it makes an exception, it would be better to call it make_exception than enable_error_info. This follows the example of std::make_pair, etc.
What is the motivation for the Logging system's string conversion behavior #3? It seems that a compilation failure would be preferable in most cases, since the silent failure of #3 to convert to a string won't be noticed until the program is completely compiled and executed. I'd rather know at compile time. This should at least be an option.
You can store any value in a boost::exception even if it can't convert to a string. For example, as I've done in the example at the end of the documentation, you can add a boost::weak_ptr<FILE> object in a boost::exception. It isn't reasonable to require the user to define a to_string overload for boost::weak_ptr, just to be able to store it in a boost::exception. Besides, even if you do require a to_string overload for boost::weak_ptr, that overload can only return something generic like "<weak_ptr>", which is similar to what you get from the fallback behavior of what() anyway.
In general, the value you store in a boost::exception could be something you can't print, but can be used to get you the thing you can print; this is beyond the scope of what().
I agree with your point, but it would also be nice to have a strict mode, so that the compiler could catch all the places that the default string was going to be produced. If I decide that I want all boost::exception instances in my code to produce useful output for all their contained data (a reasonable expectation for many validation schemes), I have no way under the current design of doing so. My only option right now is to inspect the code or run the code, trying to provoke all the exceptions. These are error-prone ways of verifying that the what() output is whatw I want, obviously. So I'd like to see something like BOOST_EXCEPTION_STRICT_WHAT, that when defined causes a compile failure for behavior #3. Zach Laine
Zach Laine wrote:
That's correct, but I think a likelier scenario for standardization would be to include Boost.Exception as-is, so that it a) does not affect any current standard library or user code, and b) retains its full usefulness (I'm thinking here of your rationale section "Why doesn't boost::exception derive from std::exception?").
It would be much more useful to add the ability to transport arbitrary data from throw to catch to std::exception itself. I believe that this doesn't contradict your a) or b) points.
Zach Laine wrote:
<snip>
It would be nice to have the actual headers linked to somewhere in the online docs.
Done. You can browse the source code, tests and everything here:
I actually meant that the online docs that you intend to submit for review would benefit from having the library's source files included as well.
OK I am confused. The source code is available and has been available for a few months now, when I did the preliminary submission, there were some discussions, changes in the design, etc. Starting this thread, with the Review Request subject line, I thought that I am submitting the library for official review. Did I miss something? What source files are you talking about?
As for the library itself, the name "exception" is fine within the context of Boost, but it's going to collide with std::exception if this is ever standardized. Is there another name for this? I have to admit, nothing better springs to mind.
Since you bring it up, please do correct me if I'm wrong but *if* this is ever standardized, it could expand the semantics of std::exception. As far as I can see, this would not break existing code because the boost::exception constructors don't allocate memory and don't throw exceptions. Besides a pointer to the internal implementation (which is the only data member of boost::exception) there is no overhead; I could not find anything in 18.6.1 that boost::exception would violate.
That's correct, but I think a likelier scenario for standardization would be to include Boost.Exception as-is, so that it a) does not affect any current standard library or user code, and b) retains its full usefulness (I'm thinking here of your rationale section "Why doesn't boost::exception derive from std::exception?"). Anyway, this isn't a major objection, just something to think about.
I guess you can add "because that way it could become std::exception" to "why doesn't boost::exception derive from std::exception".
What is the motivation for the Logging system's string conversion behavior #3? It seems that a compilation failure would be preferable in most cases, since the silent failure of #3 to convert to a string won't be noticed until the program is completely compiled and executed. I'd rather know at compile time. This should at least be an option.
<snipped> In general, the value you store in a boost::exception could be something you can't print, but can be used to get you the thing you can print; this is beyond the scope of what().
I agree with your point, but it would also be nice to have a strict mode, so that the compiler could catch all the places that the default string was going to be produced. If I decide that I want all boost::exception instances in my code to produce useful output for all their contained data (a reasonable expectation for many validation schemes), I have no way under the current design of doing so.
When you say "useful output" you do realize that the output from what() is not user-friendly, right? Displaying the information relevant to a particular error is a separate issue beyond the scope of boost::exception. The user-friendly message is composed based on the type of the exception object, and the contained values recovered by get_error_info<>. Your program has to "know" what values to expect in a particular exception type, and you're free to report missing values that are required by design.
My only option right now is to inspect the code or run the code, trying to provoke all the exceptions. These are error-prone ways of verifying that the what() output is whatw I want, obviously. So I'd like to see something like BOOST_EXCEPTION_STRICT_WHAT, that when defined causes a compile failure for behavior #3.
It seems to me that your motivation with this issue is to make the output of what() more user-friendly, and more useful. I am all for making what() more useful, but at the same time I think that such efforts must not interfere with the ability to store *any* value type in a boost::exception. Perhaps we can make the compiler issue a warning if you add to a boost::exception value type that can't be converted to string? What do you think?
On 11/14/06, Emil Dotchevski <emildotchevski@hotmail.com> wrote:
Zach Laine wrote:
<snip>
It would be nice to have the actual headers linked to somewhere in the online docs.
Done. You can browse the source code, tests and everything here:
I actually meant that the online docs that you intend to submit for review would benefit from having the library's source files included as well.
OK I am confused. The source code is available and has been available for a few months now, when I did the preliminary submission, there were some discussions, changes in the design, etc. Starting this thread, with the Review Request subject line, I thought that I am submitting the library for official review. Did I miss something? What source files are you talking about?
No, I was confused. I didn't see the "Browse the source code" at the top of the docs.
As for the library itself, the name "exception" is fine within the context of Boost, but it's going to collide with std::exception if this is ever standardized. Is there another name for this? I have to admit, nothing better springs to mind.
Since you bring it up, please do correct me if I'm wrong but *if* this is ever standardized, it could expand the semantics of std::exception. As far as I can see, this would not break existing code because the boost::exception constructors don't allocate memory and don't throw exceptions. Besides a pointer to the internal implementation (which is the only data member of boost::exception) there is no overhead; I could not find anything in 18.6.1 that boost::exception would violate.
That's correct, but I think a likelier scenario for standardization would be to include Boost.Exception as-is, so that it a) does not affect any current standard library or user code, and b) retains its full usefulness (I'm thinking here of your rationale section "Why doesn't boost::exception derive from std::exception?"). Anyway, this isn't a major objection, just something to think about.
I guess you can add "because that way it could become std::exception" to "why doesn't boost::exception derive from std::exception".
Well, I was specifically thinking of this sentence: "If boost::exception derives from std::exception, this would create a problem for enable_error_info: it is designed to make it easier to integrate Boost Exception with existing exception class hierarchies which can not be modified without a risk of breaking existing exception handling code." Standardizing boost::exception as a separate class would be more useful with respect to non-std::exception-based exception classes.
What is the motivation for the Logging system's string conversion behavior #3? It seems that a compilation failure would be preferable in most cases, since the silent failure of #3 to convert to a string won't be noticed until the program is completely compiled and executed. I'd rather know at compile time. This should at least be an option.
<snipped> In general, the value you store in a boost::exception could be something you can't print, but can be used to get you the thing you can print; this is beyond the scope of what().
I agree with your point, but it would also be nice to have a strict mode, so that the compiler could catch all the places that the default string was going to be produced. If I decide that I want all boost::exception instances in my code to produce useful output for all their contained data (a reasonable expectation for many validation schemes), I have no way under the current design of doing so.
When you say "useful output" you do realize that the output from what() is not user-friendly, right? Displaying the information relevant to a particular error is a separate issue beyond the scope of boost::exception. The user-friendly message is composed based on the type of the exception object, and the contained values recovered by get_error_info<>.
I don't necessarily want user-friendly output, I just want for users who use what() to optionally be able to know for certain that all values in what()'s output are meaningful. In other words, some users will consider it unsatisfactory if what() ever produces "file.cpp 64 <unknown>". Those users that find this unsatisfactory should have a means of preventing it. It comes down to the fact that boost::exception::what() advertises that it produces output for each associated datum, but currently it silently fails to do so if I forgot to provide the correct overload of operator<<. Since we're dealing with exception handling here, many times what() will be used to print out a bit of info right before an abort. For hard-to-reproduce exceptions, you really want all the info you can get, and finding out that you forgot to define the right operator<< overload at runtime is going to be really painful in many cases. While the increased usability of substituting "<unknown>" will probably be preferable for most use cases, it is certainly not for others.
Your program has to "know" what values to expect in a particular exception type, and you're free to report missing values that are required by design.
Sorry, I don't understand this sentence. Could you say it another way?
My only option right now is to inspect the code or run the code, trying to provoke all the exceptions. These are error-prone ways of verifying that the what() output is whatw I want, obviously. So I'd like to see something like BOOST_EXCEPTION_STRICT_WHAT, that when defined causes a compile failure for behavior #3.
It seems to me that your motivation with this issue is to make the output of what() more user-friendly, and more useful.
Not necessarily. My main aim is to provide those users that want to use what() to get at the data attached to an exception, and that want to ensure all those data are actually printed, a way to get the compiler to check for them that this is possible.
I am all for making what() more useful, but at the same time I think that such efforts must not interfere with the ability to store *any* value type in a boost::exception.
I agree. That's why I suggested that the strict mode be optional.
Perhaps we can make the compiler issue a warning if you add to a boost::exception value type that can't be converted to string? What do you think?
Well, that's a possibility, but consider this: If such a warning were on all the time, some users would complain, since many users work under the rule that their code must build without warnings. So then I think you'd probably end up defining something like the macro above anyway, so users could see the warnings or turn them off. Once you've got the macro, I think the users that turn on the warning behavior would prefer an error, since the whole point of turning it on is to catch those places in which string conversions are needed. Zach Laine
<snip> That's correct, but I think a likelier scenario for standardization would be to include Boost.Exception as-is, so that it a) does not affect any current standard library or user code, and b) retains its full usefulness (I'm thinking here of your rationale section "Why doesn't boost::exception derive from std::exception?"). Anyway, this isn't a major objection, just something to think about.
I guess you can add "because that way it could become std::exception" to "why doesn't boost::exception derive from std::exception".
Well, I was specifically thinking of this sentence: "If boost::exception derives from std::exception, this would create a problem for enable_error_info: it is designed to make it easier to integrate Boost Exception with existing exception class hierarchies which can not be modified without a risk of breaking existing exception handling code." Standardizing boost::exception as a separate class would be more useful with respect to non-std::exception-based exception classes.
Hypothetically speaking, if boost::exception functionality is directly supported by std::exception, std::enable_error_info<T>'s behavior would be to "return an object of unspecified type which derives publicly from std::exception and T". You wouldn't need to call enable_error_info with a T that derives from std::exception.
<snip> When you say "useful output" you do realize that the output from what() is not user-friendly, right? Displaying the information relevant to a particular error is a separate issue beyond the scope of boost::exception. The user-friendly message is composed based on the type of the exception object, and the contained values recovered by get_error_info<>. <snip>
It comes down to the fact that boost::exception::what() advertises that it produces output for each associated datum, but currently it silently fails to do so if I forgot to provide the correct overload of operator<<. Since we're dealing with exception handling here, many times what() will be used to print out a bit of info right before an abort. For hard-to-reproduce exceptions, you really want all the info you can get, and finding out that you forgot to define the right operator<< overload at runtime is going to be really painful in many cases. While the increased usability of substituting "<unknown>" will probably be preferable for most use cases, it is certainly not for others.
Peter Dimov suggested that another possibility is to fail if a suitable to_string overload is not found, like you want, but to be able to specify that a particular tag's value is not printable: tag_whatever: error_info_value<T,false> { }; or something similar.
Your program has to "know" what values to expect in a particular exception type, and you're free to report missing values that are required by design.
Sorry, I don't understand this sentence. Could you say it another way?
I now realize that what I meant was really a separate issue from what(), but since you're asking I'll clarify what I meant. I say "your program" to stress the fact that the error_info that arrives at catch sites is not only up to the libraries you use (where some exceptions originate), because the particular program (or application) you're working on can add its own error_info to any exception. So what I meant is that within the broader context of the application, there may be a requirement that each exception of type T must have error info for tag_a, tag_b, and tag_c, so if you catch a T that doesn't have them all, you can report it as a bug. Assuming that using tag_a, tag_b and tag_c you can format a user-friendly message, the fact that tag_b's value won't show up in what() seemed unimportant. Ultimately I agree that what() is an important debugging tool, I think we're on the same page, we just need to find the correct behavior.
Perhaps we can make the compiler issue a warning if you add to a boost::exception value type that can't be converted to string? What do you think?
Well, that's a possibility, but consider this: If such a warning were on all the time, some users would complain, since many users work under the rule that their code must build without warnings. So then I think you'd probably end up defining something like the macro above anyway, so users could see the warnings or turn them off.
Once you've got the macro, I think the users that turn on the warning behavior would prefer an error, since the whole point of turning it on is to catch those places in which string conversions are needed.
Agreed.
"Zach Laine" <whatwasthataddress@gmail.com> writes:
As for the library itself, the name "exception" is fine within the context of Boost
I'm not sure; it seems a bit generic. This library has a very specific function, and I can think of lots of other library ideas that deal with EH. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Zach Laine" <whatwasthataddress@gmail.com> writes:
As for the library itself, the name "exception" is fine within the context of Boost
I'm not sure; it seems a bit generic. This library has a very specific function, and I can think of lots of other library ideas that deal with EH.
When I see 'boost' I read 'std', and std::exception has a very specific meaning. ;-)
I found a subtle bug regarding exception::what(). I remember fixing this same bug once when it was pointed to me after the preliminary submission of Boost Exception few months ago. Aparently the fix got lost somehow! The what() function uses lazy initialization to cache the string it returns. The object that caches the returned value was not cleared (as it should be) if the exception object is later modified. It now works correctly.
Hi Emil, I have received your request and will add your Exception library to the review queue. Cheers, ron On Nov 12, 2006, at 9:36 PM, Emil Dotchevski wrote:
I believe the proposed Boost Exception library is now mature enough for formal review.
Please read the documentation at:
http://www.revergestudios.com/boost-exception/boost-exception.htm
Here is a direct link to the source code, boost build jamfiles and tests. Tested with MSVC 7.1, MSVC 8.0, GCC 3.4.4, and Comeau C++ 4.3.8:
http://www.revergestudios.com/boost-exception/boost-exception.zip
Regards, Emil Dotchevski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
participants (7)
-
David Abrahams -
Emil Dotchevski -
Felipe Magno de Almeida -
Peter Dimov -
Ronald Garcia -
Sohail Somani -
Zach Laine