Sunday, February 3, 2013

Exceptions vs Error Codes

Recently I was reading about throwing exceptions vs returning error codes, and I realized that this is a very interesting topic in programming language design that had been in the back of my head, but deserves to be properly thought through.

I don't believe that one approach is better than the other for all cases; from my point of view the biggest argument for exceptions over return codes is that with exceptions you avoid situations where errors are silently ignored (resulting in confusing results for users and difficult to debug situations for the programmer).

Basically Qore tries to be as intuitive as possible for the programmer (and obviously fails sometimes, as seen from the occasional design and interface changes as the language progresses), and therefore should try to get this right.

After thinking about it a bit, it seems to me that Qore builtin code should always throw exceptions if errors are not likely to occur (and therefore be more likely to be ignored).  Examples of this would be Socket send methods (changed from returning error codes to throwing exceptions in 0.8.6) and File write methods (even less likely to throw exceptions, already changed to throw exceptions in svn - to be released in 0.8.7 shortly).

It also seems that for code that is more likely to throw an error could justifiably return error codes instead of throwing exceptions, as ignoring the return code would be clearly bad programming practice.   If the code in question already returns a result code, then this model fits even better.

Making a language as intuitive as possible for all programmers is not easy.  Basically I can only try to do it for myself and try to think through and make educated guesses about what should work for others.  However at the end of the day, it's all about maximizing productivity.  Having silent errors in an important program could cost a lot of money to debug.  If the programming language is not intuitive, then it also costs money every time programmers get stuck on some weirdness with the language or have to debug problems caused by the same.  Intuitive programming languages are also more fun to program in.

This last point is the main reason why Qore's design was originally based on perl - I found perl very intuitive and wanted to make a language like perl that was suitable for enterprise development.  I know that quite a few programmers do not like perl, but possibly a lot of those have never programmed much in it.  Anyway, I believe Qore is getting better and better with each release, I find it more intuitive, and I hope those that are brave enough to try Qore do too.


  1. Nice, i find Qore really attractive! You hace made great progress! Congratulations!!!

    Looking forward for next release :)

  2. excellent, thanks a lot for the encouraging comment. the next release will be out very soon now - maybe even this weekend.

  3. Hi David, I happened to run across Qore last night and at first glance it looks quite nice. I've lived mostly in Java/.NET land for the past decade or so and there is a fair bit of interesting discussion about the "best" way to handle errors in those environments -- you may find it informative and interesting to search for "java exception handling best practices" or "java checked exceptions". Somewhere on thedailywtf there is a pretty good thread about them as well (it's funny how often a forum post highlighting a bit of crap code turns into a serious discussion).

    The main difficulty with all error handling is that it's usually given little thought. Many programmers are satisfied with getting the Happy Path working right, and treat error handling as an afterthought. So whatever approach you decide to take, be prepared for your errors to be ignored :).


  4. Hi Thomas,

    Thanks for your note - your comment about the "happy path working right" is exactly the point I am trying to address. I fall in to the same trap - however when an exception is thrown then normally the error isn't ignored - if there's no exception handling then the program loudly exits right at that moment.

    This is a problem for stand-alone code (however I believe that exiting with an ugly unhandled exception is better than the error being silently ignored and having strange errors in the following logic), however it's really good for embedded code, assuming that the embedding code has exception handling - in that case the embedded code simply fails with an exception at that point and the embedding code catches the exception and logs it appropriately (or sets an error status on the operation that the embedded logic was trying to perform for example).

    This is a very important use case for Qore as well (embedding Qore code within a framework also written in Qore for example).

    Anyway thank again for your thoughts - I will definitely look into the Java exception best practices you recommended.


  5. I have started using exceptions more in my code (Perl), and I see both sides. I have not yet synthesized when to use exceptions versus return codes, but there seems to be a method to the madness.

  6. I didn't know that Perl supported exceptions and exception handling until I read your comment - that's good