Exceptions were an enormous improvement for error handling in software. Previously we would have code like this:<\/p>\n
int a() {\n if( !do_something() )\n return error_code_for_a;\n return success_for_a;\n}\n\nint b() {\n if( a() == error_code_for_a )\n return error_code_for_b;\n return success_for_b;\n}\n\nint c() {\n if( b() == error_code_for_b )\n return error_code_for_c;\n return success_for_c;\n}\n\nint main() {\n if( c() == error_code_for_c )\n printf("Error in c()\\n");\n}<\/code><\/pre>\nThere are a few problems:<\/p>\n
\n- In a large application, the generator of an exceptional case has no knowledge of how to handle that exception.<\/li>\n
- The error therefore has to propagate from where it is generated to where it is handled.<\/li>\n
- Each function has to have a way of returning an error code as well as its real result; right through the chain of calls. What happens if the valid range for the non-error return value covers every possible value for that data type? There is then no way to steal one value to indicate an error.<\/li>\n<\/ul>\n
Exceptions solve these problems by giving a separate return path for exceptional values.<\/p>\n
int a() {\n if( !do_something() )\n throw exception_in_a;\n return success_for_a;\n}\n\nint b() {\n a();\n return success_for_b;\n}\n\nint c() {\n b();\n return success_for_c;\n}\n\nint main() {\n try {\n c();\n } catch( exception_in_a &e ) {\n printf("Error in c()\\n");\n }\n}<\/code><\/pre>\nNote that b()<\/code> and c()<\/code> have no ability to handle the exception, so they can simply ignore it \u00e2\u20ac\u201c the exception, should it occur, propagates right through them transparently.<\/p>\nAt first sight then exceptions solve our problems. Not so. As they come, we rely on all the information about the exception being known by the generator. That is often not the case. The classic example is a failure during read.<\/p>\n
void readSomething( int fd ) {\n if( read(fd, globalBuffer, 10) < 0 )\n throw libc_error(errno);\n}\n\nvoid openThenRead( const string &fn ) {\n fd = open(fn);\n read(fd);\n}\n\nvoid getConfigFile() {\n openThenRead("configfile.txt");\n}\n\nint main() {\n try {\n getConfigFile();\n } catch( libc_error &e ) {\n cerr << "Error reading file, errno=" << e.errno() << endl;\n }\n}<\/code><\/pre>\nWhat use is that as an error message? We have been told what the error was, but we have no way of finding out what file generated the error. Imagine of course that there are many files that may be opened in the application.<\/p>\n
Java, by custom, although not by necessity, deals with this problem by wrapping one exception in another.<\/p>\n
void readSomething( int fd ) {\n if( read(fd, globalBuffer, 10) < 0 )\n throw libc_error(errno);\n}\n\nvoid openThenRead( const string &fn ) {\n fd = open(fn);\n try {\n read(fd);\n } catch( libc_error &e ) {\n throw open_and_read_error(fn, e);\n }\n}\n\nvoid getConfigFile() {\n openThenRead("configfile.txt");\n}\n\nint main() {\n try {\n getConfigFile();\n } catch( open_and_read_error &e ) {\n cerr << "Error reading file, " << e.filename() << endl;\n try {\n throw e.innerException();\n } catch( libc_error &e ) {\n cerr << " - errno " << e.errno() << endl;\n }\n }\n}<\/code><\/pre>\nI\u00e2\u20ac\u2122ve laboured the point a little, but the idea should be clear; by wrapping one exception in another, all of the information about an exception can be gathered together.<\/p>\n
The problem is that this still has a major fault: the thrower ends up throwing at a particular target. If we have to write handlers for every combination of wrapper, and wrapped, to multiple depths, we will very quickly have to write far more handlers than is practical. Boost offers a pleasant mechanism<\/a> for tidying this up. I\u00e2\u20ac\u2122ll express the idea using a simplified syntax here, but you can get the real API from the Boost documentation.<\/p>\nvoid readSomething( int fd ) {\n if( read(fd, globalBuffer, 10) < 0 )\n throw boost::exception() << error_info_errno(errno);\n}\n\nvoid openThenRead( const string &fn ) {\n fd = open(fn);\n try {\n read(fd);\n } catch( boost::exception &e ) {\n throw e << error_info_filename(fn); \n }\n}\n\nvoid getConfigFile() {\n openThenRead("configfile.txt");\n}\n\nint main() {\n try {\n getConfigFile();\n } catch( boost::exception &e ) {\n if( e.has<filename_t>() )\n cerr << "Error reading file, " << e.get<filename_t>() << endl;\n if( e.has<errno_t>() )\n cerr << " - error number, " << e.get<errno_t>() << endl;\n }\n}<\/code><\/pre>\nThe point to observe is that openThenRead()<\/code> catches the most generic type of error, and adds its own information to it as it passes. That same principle applies at all levels; meaning that no one ever has to catch more than one exception type.<\/p>\nIt\u00e2\u20ac\u2122s not my favoured option to use boost, as convenient as it is, as for me it\u00e2\u20ac\u2122s gotten too large and unstable (it gets updated a lot, and I\u00e2\u20ac\u2122ve had some builds fail on upgrades). In a future article I\u00e2\u20ac\u2122ll describe a simpler version of boost\u00e2\u20ac\u2122s exception class.<\/p>\n","protected":false},"excerpt":{"rendered":"
Exceptions were an enormous improvement for error handling in software. Previously we would have code like this: int a() { if( !do_something() ) return error_code_for_a; return success_for_a; } int b() { if( a() == error_code_for_a ) return error_code_for_b; return success_for_b; } int c() { if( b() == error_code_for_b ) return error_code_for_c; return success_for_c; } int\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[66,90,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1134"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1134"}],"version-history":[{"count":3,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1134\/revisions"}],"predecessor-version":[{"id":1140,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1134\/revisions\/1140"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}