Comments on: The lie of C++ exceptions http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/ A blog on the development of the NGEDIT text editor Thu, 29 Jul 2010 23:54:39 +0000 http://wordpress.org/?v=2.3.2 By: The growing pains of NGEDIT » Blog Archive » Focusing my development effort http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-236 The growing pains of NGEDIT » Blog Archive » Focusing my development effort Thu, 24 Nov 2005 17:57:12 +0000 http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-236 [...] The growing pains of NGEDIT A blog on the development of the NGEDIT text editor « The lie of C++ exceptions [...] […] The growing pains of NGEDIT A blog on the development of the NGEDIT text editor « The lie of C++ exceptions […]

]]> By: J http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-229 J Fri, 18 Nov 2005 15:40:06 +0000 http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-229 Sebastian, I haven't read that book. I've been researching the subject since yesterday, and one of the articles I came up with after searching for "c++ exception strong guarantee" was by Abrahams. I also read some stuff by Herb Sutter. I plan on following up with the issue. I actually might try to nail it down, and reach a conclusion, at least with regards to my needs. Ie, conclude what it would mean to write my C++ code based around exceptions, and make my mind up for once. I have the intuition, although I'm not sure yet, that it is actually more involved than explicit error handling - I mean, in an <em>objective</em> way. Sebastian, I haven’t read that book. I’ve been researching the subject since yesterday, and one of the articles I came up with after searching for “c++ exception strong guarantee” was by Abrahams. I also read some stuff by Herb Sutter.

I plan on following up with the issue. I actually might try to nail it down, and reach a conclusion, at least with regards to my needs. Ie, conclude what it would mean to write my C++ code based around exceptions, and make my mind up for once.

I have the intuition, although I’m not sure yet, that it is actually more involved than explicit error handling - I mean, in an objective way.

]]> By: Sebastian Wagner http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-226 Sebastian Wagner Thu, 17 Nov 2005 22:35:13 +0000 http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-226 Heya, excellent thoughts, really. Regarding a pointer into the right direction, have you read "Exceptional C++" by Herb Sutter? Also, Abrahams over at boost is an exception handling guru and has written down a thing or two. Heya, excellent thoughts, really. Regarding a pointer into the right direction, have you read “Exceptional C++” by Herb Sutter? Also, Abrahams over at boost is an exception handling guru and has written down a thing or two.

]]> By: J http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-212 J Thu, 17 Nov 2005 17:00:14 +0000 http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-212 curious, Thanks for the pointer - I've started to research that framework based on guarantees. I'm probably less educated in C++ than I should, but I do dedicate a lot of thinking to try to find the fundamental issues. It actually seems the transaction semantics are described, with non-throwing in the "commit" phase being a need. At early research, I haven't seen a description of how a full framework should operate and its application in each situation - the guarantees are also tools to implement the error handling system, and I'm trying to figure out the whole policy. Anyway, I'm starting to see a way that exception-based error handling could work. Do you have a pointer to some kind of complete description? I think that, as a rule, a function needs to guarantee state to a any data which is not local (globals - yes they exist -, function arguments, and any other data obtained through them). So it must do a kind of "transaction based" operation on them. Member variables modified from methods have to be treated like that as well. Regarding your question about my "improvement", it goes along the simple line of: if (m_vector_whatever.push_back() == RET_OK) { // Explicit handling of everything: undoing, restoring well-known state, ... } I would probably be willing to move to exceptions if I can figure out the whole error generation framework - I think that even if exception handling currently impacts runtime performance, it could be optimized and it will probably be in future compilers (using whole-program analysis). curious,

Thanks for the pointer - I’ve started to research that framework based on guarantees. I’m probably less educated in C++ than I should, but I do dedicate a lot of thinking to try to find the fundamental issues.

It actually seems the transaction semantics are described, with non-throwing in the “commit” phase being a need. At early research, I haven’t seen a description of how a full framework should operate and its application in each situation - the guarantees are also tools to implement the error handling system, and I’m trying to figure out the whole policy.

Anyway, I’m starting to see a way that exception-based error handling could work. Do you have a pointer to some kind of complete description?

I think that, as a rule, a function needs to guarantee state to a any data which is not local (globals - yes they exist -, function arguments, and any other data obtained through them). So it must do a kind of “transaction based” operation on them. Member variables modified from methods have to be treated like that as well.

Regarding your question about my “improvement”, it goes along the simple line of:

if (m_vector_whatever.push_back() == RET_OK)
{
// Explicit handling of everything: undoing, restoring well-known state, …
}

I would probably be willing to move to exceptions if I can figure out the whole error generation framework - I think that even if exception handling currently impacts runtime performance, it could be optimized and it will probably be in future compilers (using whole-program analysis).

]]> By: curious http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-208 curious Thu, 17 Nov 2005 15:06:19 +0000 http://blog.ngedit.com/2005/11/17/the-lie-of-c-exceptions/#comment-208 How will you improve your example if you didn't use exceptions? One more thing you are forgetting is that there are three exception guarantees: 1. Basic - no resource leaks, object remains in a valid state. 2. Strong - same as basic, but object remains in the state before and after the expception is thrown. 3. No throw - no exceptions can be thrown. In your post you are only talking about strong guarantee, and forgetting the other two. You must decide what guarantee is appropriate for each of your classes, when building a system that uses exceptions. How will you improve your example if you didn’t use exceptions?
One more thing you are forgetting is that there are three exception guarantees:
1. Basic - no resource leaks, object remains in a valid state.
2. Strong - same as basic, but object remains in the state before and after the expception is thrown.
3. No throw - no exceptions can be thrown.

In your post you are only talking about strong guarantee, and forgetting the other two. You must decide what guarantee is appropriate for each of your classes, when building a system that uses exceptions.

]]>