Re: String corrupted after throw
From: Alf P. Steinbach (alfps_at_start.no)
Date: 03/08/04
- Next message: naruto: "Pointer and Reference"
- Previous message: rsr: "Re: DLL & GetProcAddress to find functions ref22222"
- In reply to: William Payne: "Re: String corrupted after throw"
- Next in thread: William Payne: "Re: String corrupted after throw"
- Reply: William Payne: "Re: String corrupted after throw"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 08 Mar 2004 08:54:23 GMT
* "William Payne" <mikas493_no_s_p_a_m_@student.liu.se> schriebt:
>
Not a relation of Major Payne, are you? ;-) ... Joking. Couldn't resist.
> Thanks for your reply. I was throwing a string literal at first, but I
> didn't realise it does not have automatic storage but instead exists
> throughout the life-time of the program (correct?). Then I changed to what I
> had in my first post because I wanted to include the value (the int) causing
> the exception to be included in the error message. Now, as you, suggested, I
> am throwing an object of a class derived from std::exception and catching
> const references to it. The class looks like this:
>
> class BinaryTreeError : public std::exception
class BinaryTreeError: public std::runtime_error
> {
> public:
> explicit BinaryTreeError(const std::string& error_message)
> :
> m_error_message(error_message)
:
std::runtime_error( error_message )
> {
> ; /* Do nothing. */
> }
>
> virtual ~BinaryTreeError() throw()
> {
> ; /* Do nothing. */
> }
>
> const char* what() const throw()
> {
> return m_error_message.c_str();
> }
-- remove 'what' function.
>
> private:
> std::string m_error_message;
-- remove 'm_error_message'.
> };
>
> Everything seems to work now! However, I left the call to sprintf there, the
> integer would have to contain a large value indeed for that string to
> overflow.
That's OK, but beware of floating point values.
Now, there are _three_ main reasons for deriving from std::runtime_error
instead of directly from std::exception:
1) std::runtime_error keeps track of an error message, and since it's a
standard library class it might do so more efficiently than you can.
2) std::runtime_error is the base class for ordinary runtime errors,
as opposed to for example std::logic_error.
3) In many situations it's necessary to distinguish between "hard" and
"soft" exceptions, where the former are meant to be caught only at the
highest level of the program, leading to eventual termination. So at
lower levels, catch only std::runtime_error (if anything). And throw
only std::runtime_error, except if you want the program to abort. Other
exceptions like std::bad_alloc and std::bad_cast will then have "hard"
effect automatically. One simple convention that spares you much work.
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
- Next message: naruto: "Pointer and Reference"
- Previous message: rsr: "Re: DLL & GetProcAddress to find functions ref22222"
- In reply to: William Payne: "Re: String corrupted after throw"
- Next in thread: William Payne: "Re: String corrupted after throw"
- Reply: William Payne: "Re: String corrupted after throw"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
