Different ways to report errors
Run-time errors can be reported in a few different ways in a C++ program. Throwing exceptions or returning status codes from functions are two possibilities. It is important to always check error conditions, regardless of how they are reported.
RULES
AND
RECOMMENDATIONS
Rec 12.1 Check for all errors reported from functions.
Rec 12.2 Use exception handling instead of status values and error codes.
Rec 12.1 Check for all errors reported from functions.
Rec 12.2 Use exception handling instead of status values and error codes.
In C++, the best way to report an unexpected error condition is to throw an exception.
throw EmcException("Fatal error: Could not open file");
Throwing an exception is very similar to a return statement. When a function returns, local objects will end their lifetime and their destructors will be called. The same thing happens when leaving a function by throwing an exception. A difference is that it is not obvious from reading the code which statement that will throw an exception, but is quite obvious where the function returns.
Throwing an exception is not the only way to report an error. Many programs reuse existing libraries written in C that report errors through status values and error codes instead of throwing exceptions.
A difference between these solutions is that it is not possible to ignore an exception. Unless there is a handler, a catch statement, that can handle the exception, the program will terminate. If that is the wrong behavior, the program must be modified.
It is important to handle exceptions, but it is even more important to always check status values returned from functions. If an error reported this way is ignored, there is no easy way of knowing what eventually made the program crash. Such programs must also be modified, but it is much more difficult to know where.
The socket() function is a UNIX library function that creates a communication channel between two processes. If the call succeeds, it returns a socket file descriptor that is >= 0 , otherwise -1 is returned.
// create socket int socketfd = socket(AF_UNIX, SOCK_STREAM, 0); if (socketfd < 0) // check status value { // ... }
The negative return value is a status value that only tells the user that something did go wrong, but not the reason for failure. In this particular case, the global variable errno must be used to get a description of the error.
It seems natural to check status values returned from functions, but in reality there are huge amounts of code written that does not do these checks. The fact that status values can be ignored by the programmer is one of the reasons to why exception handling in most cases is a better way of reporting errors.
Using status values only works well if all functions along a call chain are given the chance to handle the error. This requires the programmer to mix code that represents the ordinary flow of control with code that is only run when an error is reported.
With exception handling it is possible to separate code that handles errors from the ordinary flow of control. Less code will need to be written since exception handling can be localized to one function along a call chain. It is also possible to handle many different exceptions with the same piece of code by specifying a handler for either an exception base class or with ellipsis ( ... ).
try { // ordinary flow of control f(); g(); } catch(...) // handler for any kind of exception { // error handling }
An additional difficulty with status values is that constructors and some overloaded operators cannot return values, which means that a status value must either be passed as a reference argument or be stored by the object.
By using exception handling instead of status values, the functions will need fewer arguments and return values, which makes them much easier to use. Another advantage is that if you do not have any way of recovering from an error reported as an exception, you can simply ignore it and it will be propagated up along the call chain.
An additional benefit is that since an exception is an object, an arbitrary amount of error information can be stored in an exception object. The more information that is available, the greater the chance that the correct decision is made for how to handle the error.
One way to encapsulate the UNIX system calls is to provide a wrapper function that throws an exception instead of returning a status value.
class EmcException { public: // ... // EmcException objects can be printed friend ostream& operator<<(ostream&, const EmcException&); // ... }; class EmcSystemException : public EmcException { public: EmcSystemException(const char* message); // ... }; int emcSocket(int family, int type, int protocol) throw(EmcSystemException) { // create socket int socketfd = socket(family, type, protocol); if (socketfd < 0)// check status value { throw EmcSystemException("emcSocket"); } return socketfd; }
A better solution is to encapsulate the calls inside a class that represents what the socket is used for. By doing that, errors reported by functions like socket() can be translated into exceptions that are more meaningful to the user, and can also encapsulate all reasons why a particular member function failed. This will also allow the user to modify the implementation and to replace sockets with any other mechanism for inter-process communication, without revealing such changes to the user. We have not done that because we wanted to keep the example simple.