Re: [boost] [exception] ostringstream like
No, I mean that if you do advanced string manipulation in the exception itself, you may screw up, adn cause a bad_alloc beign thrown and masking your own exception.
Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error.
Just make your own, informative exception type deriving from logic_error. The problem is not really the kind of exception, but an easy way to create message with boost exception tag system.
The idea is to create a new base class for tags allowing to use an ostringstream with tags, which is not possible. typedef ::boost::error_info<struct tag_message,std::ostringstream> message; This little class only remap operator+ call to operator<< on an internal ostringstream. typedef ::boost::error_info<struct tag_message,::boost::error_info_sstream> message; I use it in my code, but I ask here if we can hope to see such things in boost exception. I would prefer to use a standard boost object rather than a custom class.
Create an error sentence with some values inside is not really an advanced string manipulation. You can have 2 kinds of errors: bug inside a custom operator<< or a memory problem. There is no particular reason to not have sufficient memory to create an error sentence when throwing something like a logic_error. You can't know as you're in an exceptionnal case already so anything's
On 16/08/10 16:21, Fabien Castan wrote: possible
The problem is not really the kind of exception, but an easy way to create message with boost exception tag system. This has nothign to do with exception. Nothign prevent you to make your own build_message(Exception const& e) that does this using boost::diagnostics_info or what not. This little class only remap operator+ call to operator<< on an internal ostringstream. What if you work on a platform with exception handlign but no usable ostream implementation ?
On Mon, Aug 16, 2010 at 7:21 AM, Fabien Castan <fcastan@quintaindustries.com> wrote:
Create an error sentence with some values inside is not really an advanced string manipulation.
The problem is that you're composing a message for the user at the time you're reporting the error. This is incorrect because: 1) The code that detects and reports the problem may not have enough information available to compose the error message; 2) The message may have to be localized. Imagine having to support 20 different languages with different grammars, in all places where you throw exceptions! Consider the following error handling strategy: 1) At the point of the throw, put only the information you have (for example, error code, etc.) in an exception and throw; 2) In contexts higher up the stack, catch(boost::exception&), add more relevant information (such as a file name, etc.) and rethrow; 3) Let the catch site deal with formatting a user-friendly message from the information stored in the exception. 4) In a top-level context, catch(...) and log the string returned by boost::current_exception_diagnostic_information() which isn't user-friendly but it is generated automatically and contains information that can hopefully tell you what went wrong so you can add the missing catch. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
[I just noticed this in my drafts folder.] Fabien Castan wrote:
No, I mean that if you do advanced string manipulation in the exception itself, you may screw up, adn cause a bad_alloc beign thrown and masking your own exception.
Create an error sentence with some values inside is not really an advanced string manipulation.
The proposed message construction may not involve advanced string manipulation, by some definition of "advanced," but what you propose is non-trivial and involves a good deal of free store (de)allocation. It is far better to store state that can be used to produce an error message at the point the message is wanted. Otherwise, the risk is of doing work to produce a message that may not be needed, while adding the risk of exhausting memory. Adding an insertion operator is likely to make formatting messages too easy in contexts where code should be concerned with simply storing state for consumption elsewhere. Thus, it would encourage bad practice. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (4)
-
Emil Dotchevski -
Fabien Castan -
joel falcou -
Stewart, Robert