Sign in to follow this  

c++ exceptions, (try/catch)

This topic is 2540 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all,

I'd like to hear opinions on exception handling in C++. I've never realy seen the advantages of exceptions over if-statements to check if things go smoothly. Sure, a try/catch might be more elegant because you can separate the exceptions from the main code, but it can also create a lot of problems. Especialy when using a combination of pointers and functions that might trow exceptions, you can easily cause memory leaks in your application.

Also, you can't see what kind of exceptions might get trown by the function just by looking at it. How do I know if and what exceptions are being thrown by vector.push_back() to give an example? What is wrong with a true/false return type to let the client know if everything went alright?

Please enlighten me :)

Greetings,
Rob

Share this post


Link to post
Share on other sites
Quote:
Original post by Toadhead
What is wrong with a true/false return type to let the client know if everything went alright?
Distance between the error and the place where error recovery can occur.

Lets say you try to allocate a new vertex buffer deep inside your rendering loop, and the allocation fails (card out of memory, or some such). Now, you are deep in the middle of the render loop, which means you can't do a damn thing about it here and now. The best you can do is pass the error up the chain of function calls, all the way to the outer loop, which is in a position to make an executive decision (such as 'reduce quality of textures to save space').

Exceptions are designed to solve the whole 'pass it up the chain' part of the problem. Passing return codes manually from each function (potentially hundreds deep) is a nightmare, and every function along the way has to figure out what the error is, and perform suitable resource cleanup.

Quote:
Especialy when using a combination of pointers and functions that might trow exceptions, you can easily cause memory leaks in your application.
You should be using smart pointers, std::auto_ptr, etc. to make sure that cleanup happens *automatically* when an exception occurs. In this way there can be no leaks, without all the margin for error that exists with manually cleanup...

Share this post


Link to post
Share on other sites
It's impossible to give a list of all the possible exceptions std::vector<>::push_back() as it's a template class that minimally depends on two different template parameters: the contained type and the allocator. Calling push_back() therefore can throw whatever exceptions the allocator does when allocating memory and whatever exceptions the copy constructor of the contained class can throw. However, generally all you really need to know about a function is if it can throw exceptions or not. In the standard library functions that can't throw exceptions are declared with the throw() exception specifier and those that can't aren't.

Share this post


Link to post
Share on other sites
Proper exception-oriented code is much more robust, for a handful of reasons:

  • Stack unwinding automatically propagates the error directly to where it can be handled immediately, based on exception type filters

  • It forces you to properly use RAII and other exception-safety techniques, which make resource leaks and "zombie state" objects virtually impossible

  • There is no way in C++ to signal an error state in a class constructor without resorting to zombie objects or using exceptions

  • Wrapping code strategically in try/catch blocks or function-try blocks can help catch unexpected or fatal errors that propagate outside any context where they could potentially be handled. For much software this is incredibly attractive because it lets you handle failures by recording as much information as possible and providing a useful error to the user, rather than just abnormally terminating as is typical in return-error-code implementations.

  • Similar errors can be handled in physically proximal locations in code, which is beneficial because this usually corresponds directly to the runtime context in where the errors can best be responded to



That said, writing truly exception-safe code in C++ is extremely difficult, so consider it carefully before making a decision. Learning proper exception safety will make you a much better C++ programmer, but may not be worth the effort for small/educational projects.

Share this post


Link to post
Share on other sites

This topic is 2540 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this