Writing exception-safe code

Dear all,

I think we’ve shortly discussed these topics here already but never reached a point where we decided how we do stuff in Calitko. I remember saying that I’ve never used exceptions in Calitko so far because I don’t truly understand them, i.e. I couldn’t say, in general, when their usage is appropriate. Well, it was high time I read something on the topic ;-). Here are some of links I came across and I consider would be interesting for you as well:

http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html
http://www.cs.nott.ac.uk/~pni/Papers/Notes/exceptions-unsafe.html
http://www.scottcollins.net/articles/exceptions.html
http://neil.fraser.name/writing/exception/
http://www.research.att.com/~bs/3rd_safe0.html
http://www.boost.org/more/generic_exception_safety.html
http://www.parashift.com/c++-faq-lite/exceptions.html

What I learn from these articles is that writing exception-safe code is extremely important and in practice not easy. Writing code that is exception-safe is the first step before writing code that uses exceptions. Most of current Calitko code is not really exception-safe, so all further refactoring work should be done with exception-safety in mind. One problem with that is that probably not all Calitko developers would be aware of these issues. What we could do is add a section to our coding conventions on exception-safety with links to additional, more detailed, resources. Additionally, more experienced developers could do more code review to identify problems and create new tickets in Calitko Trac.

I’m posting with the hope that some of you would share your own experiences and ideas how to address the issue.

Best regards,

Peter

Would you like to post a relpy?


This post starts a thread.
Follow-ups:
Re: Writing exception-safe code
Dear mate Yes a very important topic indeed... I remember Herb Sutter classifying exception safety as 1. Basic exception safety This makes sure that when you throw, stack unwinding releases resources. 2. Strong exception (more...)