Please create an account to participate in the Slashdot moderation system


Forgot your password?

The Scourge of Error Handling 536

CowboyRobot writes "Dr. Dobb's has an editorial on the problem of using return values and exceptions to handle errors. Quoting: 'But return values, even in the refined form found in Go, have a drawback that we've become so used to we tend to see past it: Code is cluttered with error-checking routines. Exceptions here provide greater readability: Within a single try block, I can see the various steps clearly, and skip over the various exception remedies in the catch statements. The error-handling clutter is in part moved to the end of the code thread. But even in exception-based languages there is still a lot of code that tests returned values to determine whether to carry on or go down some error-handling path. In this regard, I have long felt that language designers have been remarkably unimaginative. How can it be that after 60+ years of language development, errors are handled by only two comparatively verbose and crude options, return values or exceptions? I've long felt we needed a third option.'"
This discussion has been archived. No new comments can be posted.

The Scourge of Error Handling

Comments Filter:
  • by Anonymous Coward on Saturday December 08, 2012 @12:42PM (#42225631)
    Exceptions should NOT be used for 'normal' errors. They should be used for events that are, well, exceptional. A healthy program should NEVER raise an exception, but may deal with a lot of error conditions.
  • Exceptions in C++ (Score:4, Insightful)

    by Anonymous Coward on Saturday December 08, 2012 @12:45PM (#42225651)

    While I have seen good error handing schemes in many languages, so far, I haven't seen anything as good as C++ exceptions combined with RAII. Exceptions alone aren't that great, but if you combine it with the way constructors / destructors work and compose in C++, it ends up working really well. A lot of languages with exceptions lack RAII. Java and C# have exceptions but don't have destructors (the language equivalent is much less useful than C++) much less ones that compose.

    The only real problem is that lots of C++ code rely on return codes, no error handling at all, or poor use of exceptions and resource management. There are lots of C++ programmers who stumble on error handling code and haven't learned how to take advantage of the tools the language provides. Of course error handing logic can be quite hard, even if the language helps out a lot.

    STM is also a great way of doing error handling. Transactions (like used in databases) make error conditions much easier. But they cannot be limited to databases; transactions in the file system (Microsoft has this with NTFS) and transactions in memory data structures (STM) are very valuable.

  • Exceptions (Score:3, Insightful)

    by vargad ( 1948686 ) on Saturday December 08, 2012 @12:49PM (#42225681)
    Normally exceptions should be used in exceptional cases, not in normal control flow. Exceptions are usually quite expensive, especially in C++ compared to just returning an error code. Language APIs should be fast, but also convinient so they had to made a trade-off.
  • by erroneus ( 253617 ) on Saturday December 08, 2012 @12:51PM (#42225689) Homepage

    It is not clutter. It is necessary. Trash cans in the home might be considered clutter too I suppose. Some people artfully conceal them within cabinets and such, but in whatever form, they are both necessary and either take up space or get in the way or both.

    It is the reality we live in. If you want to code in a language that doesn't require error handling, you might look to one of those languages we use to teach 5 year olds how to program in.

    Good code does everything needed to manage and filter input, process data accurately and deliver the output faithfully and ensuring that it was delivered well. All of this requires error checking along the way. If you leave it to the language or the OS to handle errors, your running code looks unprofessional and is likely to abort and close for unknown causes.

    I think the short of this is that if anyone sees error checking as clutter or some sort of needless burden, they need to not code and to do something else... or just grow up.

  • Third option (Score:5, Insightful)

    by wonkey_monkey ( 2592601 ) on Saturday December 08, 2012 @12:57PM (#42225735) Homepage

    How can it be that after 60+ years of language development, errors are handled by only two comparatively verbose and crude options, return values or exceptions? I've long felt we needed a third option.

    Maybe - and admittedly this is just a guess from my fairly ignorant viewpoint - it's a very hard problem. How can it be that after 100+ years of industrial development, we're still heavily reliant on internal combustion engines to get us around? Why have we only got people as far as the moon in 60 years of space travel? Why, after x years, have we only achieved y?

    Because that's the way it is. Is there some reason we should have the third option by now?

  • by White Flame ( 1074973 ) on Saturday December 08, 2012 @12:58PM (#42225737)

    The author commends the use of multiple return values and a side-band error value that must be checked? Gee, multiple return values have been in Lisp forever, and maybe he's not aware of this little thing called "errno"?

    Error handling is very, very tedious by nature. There are bajillions of ways that a system can go screwy, and many of these have individualized responses that we want distinguished for it to behave intelligently in response. We expect computers to become "smarter", and that means reacting intelligently to these problematic/unexpected situations. That is a lot of behavioral information to imbue into the system, all hooked into precise locations or ranges for which that response is applicable. That information is hard to compress.

  • by pla ( 258480 ) on Saturday December 08, 2012 @01:02PM (#42225779) Journal
    You'd never do this on purpose, but its rather easy to accomplish in practice.

    You have too much faith in humanity, friend!

    I hate hate hate the exception-handling model of dealing with errors, because in practice, I've seen very, very little code that actually handles the error. People either:
    1) Use far too coarse grained a "try" (as in, on the entire function), giving almost no possibility of knowing what actually happened or how to recover,
    2) Use the "catch" just to tell the user "golly, it broke, try again later" rather than accidentally revealing the ugly (but meaningful) exception text,
    3) Assume nothing in the "try" could actually fail and only do it to satisfy their company's code auditors, so the catch does... nothing, or
    4) (My "favorite") - copy the entire body of the "try" into the "catch" and blindly do it again!

    When used correctly, exception handling doesn't make your code cleaner, it reduces to a slightly more verbose way of checking return values. You should, if you want any hope of really dealing with the error, wrap every call in its own try/catch. I have not ever seen that done (and honestly, I can't claim I do it as religiously as I should either - I tend to trust my own code (big mistake), and only do that for external calls).

    Then again, how do you handle the system volume suddenly vanishing out from under you? So, perhaps the coarse-grained "golly, it broke, try again later" folks have the right idea. ;)
  • by pla ( 258480 ) on Saturday December 08, 2012 @01:11PM (#42225861) Journal
    A well written program doesn't NEED an error handler.

    Okay, tough-guy... "The specified network name is no longer available". Explain how you avoid needing to handle that.
  • by Simply Curious ( 1002051 ) on Saturday December 08, 2012 @01:16PM (#42225903)
    I would say that it is much less verbose in the case where errors need to be propagated upward. This is exactly why not every function call has a try/catch around it. Suppose I am writing a function that accepts a filename, interprets the text in the file, and then returns some modified version of the text. With error codes, I would need to explicitly check that open_file has returned a valid file handler. I can't do anything without a valid file, so I then need to propagate the error upward. On the other hand, with exceptions, I could simply not catch that exception from open_file. I can't do anything to recover, so I should let the exception propagate upward to wherever called me, and then let them deal with it.
  • by gman003 ( 1693318 ) on Saturday December 08, 2012 @01:20PM (#42225947)

    There are two ways to do error-handling: try{}catch{}, or if{}else{}. That's "using exceptions" and "using return values", under Dobb's naming.

    The difference in usage is simple: one handles errors immediately, thus cluttering the code with all the things that could go wrong, while the other separates error-handling out, pushing it to the end of a block (and away from the code that actually generates the error, which can complicate debugging).

    I can really think of no other way to do it. You can handle the error where it happens, or handle the error at the end. I tend to look on anyone whining about how hard error-handling is with suspicion - their suggestions (if they even have any) are almost always "the language/compiler/interpreter/processor/operating system should handle errors for me", and there are enough obvious flaws in that logic that I need not point them out.

  • Re:Errors (Score:2, Insightful)

    by Smallpond ( 221300 ) on Saturday December 08, 2012 @01:24PM (#42225975) Homepage Journal

    All code is just assembly language in other clothing.

  • I read the article (Score:4, Insightful)

    by iplayfast ( 166447 ) on Saturday December 08, 2012 @01:27PM (#42226003)

    And I must say that as the Editor in Chief he has a very simplistic view of the problem. If I understand, his view is that a global exception added at the compiler level would somehow solve all the problems. He gives the example of calling "open" without worrying about it failing. Of course he doesn't state how to handle the failure when it occurs. For example

    open(file1); // ok
    open(file2); // failure

    What happens to file1 in this case? How is the code cleaned up? There may be a case where you don't want to just close all files in the functions, but just create file2 if the open failed. (for example).

    His complaint is that there is too many options available for error handling, and that they lead to cluttered code. As far as I can see the alternative is not enough options available and code not always doing what you want, and having to fight the compiler in order to get what you want.

  • by ruiner13 ( 527499 ) on Saturday December 08, 2012 @01:27PM (#42226007) Homepage
    I believe the reason for not wanting to throw exceptions unless really needed is that exceptions (and their handling) are relatively expensive and resource intensive operations. Most languages when exceptions are thrown do a lot of runtime stack analysis to, among other things, get a full stack trace. There are many research links on the interweb explaining how expensive it is in whatever language you happen to be using, but here is the first link I found: []

    In the case of the .net runtime, throwing an exception was > 1000x as expensive as using a return value, in processing time.
  • by mrvan ( 973822 ) on Saturday December 08, 2012 @01:30PM (#42226027)

    I think you are focussing too much on java-style compiler-forced error handling. To me, the essence of try/catch error handling is that you only catch errors if you can deal with them. If you can't (the majority of cases), let is escalate, all the way up to the user (or a log file) if needed. I think there are three sane ways of using a try/catch: (1) to actually deal with the error (this is by far the rarest), (2) mainly in loops of more-or-less independeny actions: to log the error, reset state, and continue working, and (3) at the top level, to log the error and display something less meaningful but less scary to the end user.

    I think it is a bad design decision to impose static checking on declared 'throws' statements, because that forces routines to catch stuff that they can't handle, or declare a meaningless list of everything every called routine could ever throw. In essence, it couples the signalling and handling again that exceptions were supposed to decouple.

    Another nicety of exceptions compared to return values is that the semanitcs of "something went wrong" is clear. This makes it possible to e.g. have a wrapper function that begins a transaction and commits or rollbacks it depending on the outcome (e.g. [])

  • by Sarten-X ( 1102295 ) on Saturday December 08, 2012 @01:46PM (#42226133) Homepage

    If you're actually seeing #4 in practice, your coworkers need a nice bit of physical re-education.

    Each situation you describe has perfectly valid circumstances:

    1) Using a "try" on the whole function is suitable on functions where a particular caught exception can only mean one thing. If you're catching a FileNotFound exception, it means the file's missing. It doesn't matter that the error happened while opening the file, or at the first read. The exceptional situation is that the file can't be found. Exactly which call had the exception doesn't matter beyond debugging (for which there's usually extra information in the exception, such as line numbers).

    2) Revealing ugly text isn't user-friendly. Rather, it shows that the programmer has no idea what's going on and is putting the burden of debugging on the user. Ideally, the exception handler will first take steps to remedy the situation on its own (config file not found? Use sane defaults and save them for next time!), then log the exception somewhere with only the meaningful parts (such as a module name, line number, and a selection of parameters). Nobody really needs to know the whole stack trace up to main().

    3) Sometimes, an empty catch routine is fine, and if it isn't fine a good code audit should notice this anyway. Some errors can be safely discarded, but the code should reflect that they are being willfully ignored, rather than just ignored out of ignorance.

    4) Despite my glib comment earlier, there are also cases where blindly retrying a step is the cleanest solution. One example I've seen recently is where a database connection would reveal a timed-out disconnection only upon actually executing statements. The straightforward solution was that if the first statement failed due to a timeout, the connection (which was now in an error state) would be checked again, reconnected, and the statement would be retried.

    You should, if you want any hope of really dealing with the error, wrap every call in its own try/catch. I have not ever seen that done...

    ...because it's a silly idea. Now you're just using exceptions as special return values. Exceptions are not supposed to mean "something went wrong here". They should mean "there's a situation that is so unexpected that I don't know how to handle". It's a different paradigm entirely. The idea is that rather than writing your program to anticipate every possible error (as the mathematicians so loved), the program should instead follow a more practical "hope for the best, plan for the worst" design. Rather than worrying about exactly which byte of a file couldn't be read, the program should just understand that something's wrong with the file, and its contents can't really be trusted.

    Then again, how do you handle the system volume suddenly vanishing out from under you? So, perhaps the coarse-grained "golly, it broke, try again later" folks have the right idea. ;)

    If your program is supposed to run on transient resources (like, for instance, a cluster that has a weak master controller running your program, and the bulk of its processors scheduled to run computation), this should be expected. Perhaps a "system vanished" exception can be raised to signal that in-process calculations should be restarted the next time the system appears, and that previous calculations should be saved in case everything else disappears, too.

    Or in other words, it broke and you should prepare to try again later. :)

  • Re:Exceptions (Score:5, Insightful)

    by Anonymous Brave Guy ( 457657 ) on Saturday December 08, 2012 @02:15PM (#42226369)

    Speed is another reason why current exception handling mechanisms are insufficient.


    Whether I'm aborting due to an error or exiting early from an intricate recursive graph processing algorithm, I'm still only doing it once.

    On the other hand, adding extra conditions on every pass around a nested loop to check whether a flag is set to cause an early exit creates code you're going to run lots of times (but only actually helps once).

    And in any case, for reasons I explained in my first post to this subthread, exceptions can actually be faster than relying on things like flags and error codes in both exceptional and non-exceptional code paths, obviously depending on your language's implementation strategy.

  • by gbjbaanb ( 229885 ) on Saturday December 08, 2012 @02:26PM (#42226465)

    yes you really do care. Once you've started using exceptions for normal things, then you quickly find your program will be throwing the buggers all the time. In many server applications you'll be getting 3 or 4 exceptions per request (I see this, even in the Microsoft code that you have no control over)

    net result: really slow code, exceptions don't just run slowly, they also screw your CPU caches and other bits that we rely on to get data through the CPU as quickly as it can handle it - a CPU today, if it had to fetch instructions from main RAM every time, would run about as quickly as a old 8bit computer.

    So using an exception to return the fact that you have no network connectivity (a condition you'd usually expect to be either exceptional - when the network goes down - or a non-performance issue - in that the user can't do anything). Using an exception to handle a missing entry in a data collection (eg so you can then take steps to populate it) will kill you. Too bad that I see exceptions used for this kind of behaviour :(

  • Re:Pfff (Score:4, Insightful)

    by larkost ( 79011 ) on Saturday December 08, 2012 @03:26PM (#42226913)

    I somewhat agree with you, but your examples are horrible: the near-requirement for header files and prototype functions in C stemms from a language deficiency, not from something that "beginner CS students" don't get. They are correctly seeing the situation as non-optimal. Java any Python have both (in differnt ways) are examples of langauages that handle these things with a multi-step parse. Note that I am not arguing aginst the option of having headder files, since they clearly have a use in large project (one that javadoc also servers). But the requirement to have function prototypes in order to have out-of-order functions is simply a language deficiency. The fact that people have been very sucessful while working around it for so long is a testiment to them, not to the language's inherint merit.

  • by Ziggitz ( 2637281 ) on Saturday December 08, 2012 @03:40PM (#42227033)

    This. It's not difficult to write good defensive programs that check for nulls before performing operations and can fairly consistently never raise an exception. However, most programs need to handle inputs from other applications that the program cannot guarantee are valid, a lot of complex inputs cannot be verified by simply null checks. Additionally any developer who writes code that touches the internet(i.e. most of us) have to cope with unreliable services, deployment engineers, or worse the lack thereof setting up applications with incorrect configurations, bad inputs and network failures.

    What a try catch block should really be used for, is a conscious decision point to identify where a valid program might meet an error conditions and deal with the implications of that error. Maybe the error is not finding crucial initialization parameters and all you can do is log an error, set a pretty error message for the user and kill the program. Maybe you can flush the current parameters and try again with some defaults. Maybe you can still run but with impaired functionality. Maybe you are a secondary function and it's ok if you fail but you need to let the user know.

    The author's arguments boil down to "try catch blocks make my code look ugly." There is no valid solution to error handling that doesn't involve developers proactively identifying and addressing unreliable operations. Any valid solution that isn't current exception handling is going to look a lot like it because error handling is not some boilerplate task that you can wave a magic wand at and make disappear.

  • by BitZtream ( 692029 ) on Saturday December 08, 2012 @05:16PM (#42227885)

    You're fired.

    unless you waste a lot of time reading the documentation for every class that you use

    Again I say, you are fired. I would throw you out on your ass so quick it would make your head spin if you told me that as one of my employees. If you aren't reading the documentation you don't know how the method works and you don't need to be writing code.

    That is the most idiotic argument I've ever heard. Its the definition of bad programing, ON PURPOSE no less.

  • by AmiMoJo ( 196126 ) * <> on Saturday December 08, 2012 @07:16PM (#42228827) Homepage Journal

    What a douchbag you are. In the real world there are deadlines and never enough people on hand, so you don't have time to read every bit documentation for everything. That is perfectly acceptable as long as you are still capable of developing software that is robust and does what the customer wants.

    This is why we have testing. It is more cost effective to avoid getting bogged down in making something perfect and instead get it tested as you go, making improvements based on feedback. The only people who do it any other way are writing mission critical code that costs a fortune to develop.

    You know what? You're fired. Your products are all late, way over budget, the development team hates your anal retentive attitude, while your competitors left you in the dust.

  • by SplashMyBandit ( 1543257 ) on Sunday December 09, 2012 @12:33AM (#42230757)

    I agree, C# is a nice language. The failure of C# is that *the libraries* are not cross-platform. Note that the Mono libraries are not used by the majority of C# developers, and the Mono libraries are incomplete compared to the Microsoft ones, and will never be complete according to the Mono roadmap.

    With the world becoming more and more heterogenous with regard to CPU (ARM & x86/64), Operating System (Linux, Android, Mac, Windows) and environment (embedded, rich client and web) then cross-platform matters more than ever.

    The language benefits of C# over Java do not compensate for the massive superiority of Java for cross-platform development due to the huge number of fully cross-platform Java libraries. This is why forward-looking people prefer Java, despite the fact that C# has a few nice constructs. Does that make sense?

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet