Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are many requirements needed for a system to properly convey and handle exceptions. There are also many options for a language to choose from to implement the concept.

Requirements for exceptions (in no particular order):

  1. Documentation: A language should have a mean to document exceptions an API can throw. Ideally this documentation medium should be machine usable to allow compilers and IDEs to provide support to the programmer.

  2. Transmit Exceptional Situations: This one is obvious, to allow a function to convey situations that prevent the called functionality from performing the expected action. In my opinion there are three big categories of such situations :

    2.1 Bugs in the code that cause some data to be invalid.

    2.2 Problems in configuration or other external resources.

    2.3 Resources that are inherently unreliable (network, file systems, databases, end-users etc). These are a bit of a corner case since their unreliable nature should have us expect their sporadic failures. In this case are these situations to be considered exceptional ?

  3. Provide enough information for code to handle it: The exceptions should provide sufficient information to the callee so that it can react and possibly handle the situation. the information should also be sufficient so that when logged this exceptions would provide enough context to a programmer to identify and isolate the offending statements and provide a solution.

  4. Provide confidence to the programmer about the current status of his code's execution state: The exception handling capabilities of a software system should be present enough to provide the needed safeguards while staying out of the way of the programmer so he can stay focused on the task at hand.

To cover these the following methods were implemented in various languages:

  1. Checked Exceptions Provide a great way to document exceptions, and theoretically when implemented correctly should provide ample reassurance that all is good. However the cost is such that many feel it more productive to simply bypass either by swallowing exceptions or re-throw them as unchecked exceptions. When used inappropriately checked exceptions pretty much looses all it's usefulness. Also, checked exceptions make it difficult to create a API that is stable in time. Implementations of a generic system within a specific domain will bring it's load of exceptional situation that would become hard to maintain using solely checked exceptions.

  2. Unchecked Exceptions - much more versatile than checked exception they fail to properly document the possible exceptional situations of a given implementation. They rely on ad-hoc documentation if at all. This creates situations where the unreliable nature of a medium is masked by an API that gives the appearance of reliability. Also when thrown these exceptions loose their meaning as they move back up through the abstraction layers. Since they are poorly documented a programmer cannot target them specifically and often needs to cast a much wider net than necessary to ensure that secondary systems, should they fail, do not bring down the whole system. Which brings us right back to the swallowing problem checked exceptions provided.

  3. Multistate return types Here it is to rely on a disjoint set, tupple, or other similar concept to return either the expected result or an object representing the exception. Here no stack unwinding, no cutting through code, everything executes normally but the return value must be validated for error prior to continuing. I have not really worked with this yet so cannot comment from experience I acknowledge it resolves some problems exceptions bypassing the normal flow but still it will suffer from much the same problems as the checked exceptions as being tiresome and constantly "in your face".

So the question is :

What is your experience in this matter and what, according to you is the best candidate to make a good exception handling system for a language to have ?

EDIT: Few minutes after writing this question I came across this post, spooky !

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

In the early days of C++ we discovered that without some sort of generic programming, strongly typed languages were extremely unwieldy. We also discovered that checked exceptions and generic programming didn't work well together, and checked exceptions were essentially abandoned.

Multiset return types are great, but no replacement for exceptions. Without exceptions the code is full of error-checking noise.

The other problem with checked exceptions is that a change in the exceptions thrown by a low-level function forces a cascade of changes in all the callers, and their callers, and so on. The only way to prevent this is for each level of code to catch any exceptions thrown by lower levels and wrap them in a new exception. Again, you end up with very noisy code.

share|improve this answer
Generics do help solving a whole class of errors that are mostly due to a limitation of the language's support to OO paradigm. still though, the alternatives seem to be to either have code that mostly do error checking or that runs hoping nothings ever goes wrong. Either you have exceptional situations constantly in your face or live in a dream land of fluffy white bunnies that turn real ugly when you drop a big bad wolf in the middle ! –  Newtopian May 30 '11 at 17:04
+1 for the cascading issue. Any system/architecture that makes change difficult only leads to monkey-patching and messy systems, no matter how well-designed the authors thought they were. –  Matthieu M. May 30 '11 at 17:08
@Newtopian: if the wolf shows up rarely enough, and it's not too expensive to clean up after him, ignoring him may be fine. –  kevin cline May 31 '11 at 0:41
@Newtopian: Templates do things that can't be done in strict object orientation, such as provide static type safety for generic containers. –  David Thornley May 31 '11 at 18:26
I would like to see an exception system with a concept of "checked exceptions", but one very different from Java's. Checked-ness should not be an attribute of an exception type, but rather throw sites, catch sites, and exception instances; if a method is advertised as throwing a checked exception, that should have two effects: (1) the function should handle a "throw" of the checked exception by doing something special on return (e.g. setting the carry flag, etc. depending upon the exact platform) which calling code would be required to be prepared for. –  supercat Jan 8 '13 at 18:31
show 2 more comments

I'm currently in the middle of a rather large OOP based project/API and I have used this layout of the exceptions. But it all really depends of how deep you want to go with the exception handling and the like.

- AuthorisedException
- EmptySetException
- NoRemainingException
- NoRowsException
- NotFoundException
- ValidationException

- ConnectivityException
- EnvironmentException
- ProgrammerException
- SQLException


   $valid_types = array('mysql', 'oracle', 'sqlite');
       if (!in_array($type, $valid_types)) {
           throw new ecProgrammerException(
        'The database type specified, %1$s, is invalid. Must be one of: %2$s.',
    join(', ', $valid_types)
share|improve this answer
If the exception is expected, it isn't really an exception. "NoRowsException"? Sounds like control flow to me, and therefore a poor use of an exception. –  qes May 31 '11 at 16:09
@qes: It makes sense to raise an exception whenever a function is unable to calculate a value, e.g. double Math.sqrt(double v) or User findUser(long id). This gives the caller the freedom to catch and handle errors where it is convenient, instead of checking after each call. –  kevin cline May 31 '11 at 20:17
Expected = control flow = anti-pattern of exception. Exception shouldn't be used for control flow. If it's expected to produce error for specific input, then it just be passed a a part of return value. So we have NAN or NULL. –  Eonil Dec 4 '13 at 5:15
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.