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.

Some programming languages like e.g. Scala have the concept of Option types (also called Maybe), which can either contain a value or not.

From what I've read about them they are considered widely to be a superior way of dealing with this issue than null, because they explicitly force the programmer to consider the cases where there might not be a value instead of just blowing up during runtime.

Checked Exceptions in Java on the other hand seem to be considered a bad idea, and Java seems to be the only widely used language that implements them. But the idea behind them seems to be somewhat similar to the Option type, to explicitly force the programmer to deal with the fact that an exception might be thrown.

Are there some additional problems with checked Exceptions that Option types don't have? Or are these ideas not as similar as I think, and there are good reasons for forcing explicit handling for Options and not for Exceptions?

share|improve this question
    
Also see the Either e a datatype. –  Matt Fenwick Mar 29 '13 at 13:55
3  
About checked exceptions: as a user of multitude of open source and internal Java libs with evolving code base and missing/outdated docs, I shudder at the thought that Java would not enforce certain exceptions to be explicitly declared. It would be a nightmare of unhandled runtime errors popping up at bad places, unexpectedly. And Java7 finally makes exception handling almost sane, getting rid of much of the old try-catch clutter. –  hyde Mar 29 '13 at 17:45

3 Answers 3

Because Options are composable. There are a lot of useful methods on Option that allow you to write concise code, while still allowing precise control on the flow: map, flatMap, toList, flatten and more. This is due to the fact that Option is a particular kind of monad, some objects that we know very well how to compose. If you did not have these methods and had to pattern match always on Option, or call isDefined often, they would not be nearly as useful.

Instead, while checked exceptions do add some safety, there is not much you can do with them other than catching them or let them bubble up the stack (with the added boilerplate in the type declaration).

share|improve this answer

While related, exceptions and Maybe objects do not deal with the same type of problems.

Exceptions

Exceptions really shine when you have to deal non-locally with an exceptional situation (which in some cases happens to be an error). For example you are parsing a csv, and want to protect yourself against lines with wrong formatting. The place where you find that something is wrong may be some function calls away from the line iteration. If you throw an exception at the deepest level (where you find out about the formatting issue), you can catch it in the loop, log the error, and proceed to the next line. You don't have to modify anything in the rest of the code.

Checked exception adds a lot of pain because all the intermediate functions have to declare the throwable type. The feature defeats the original purpose, which is why they are not popular nowadays.

Maybe objects

Maybe objects should be choosen when you are able to deal locally with a "failure". In that sense, they are a replacement for a return code + pass by reference api or a nullable type.

The advantage of the Maybe object is that you explicitly declare that something might be wrong. In haskell, a non maybe object has to have a value, or else the program won't compile.

The problem with nullable types is that you have to check for null all the time to be absolutely safe. The "something might be wrong" state is the default one.

The problem with return codes + pass by ref apis is that they are less readable for most people.

share|improve this answer
1  
@MattFenwick thanks for the feedback. Why do you think that the csv example doesn't make sense? The OP does not really ask for boilerplate-avoidance techniques, and I have the feeling that vocabulary such as applicative functor & monads may be too technical for this question. –  Simon Mar 29 '13 at 14:04
1  
I'd like to point out, that with Java (not sure of other languages with checked exceptions) IDEs take care of adding and pruning throws and updating javadoc comments boilerplate part. So at least that part is no bother and certainly no pain. Whether it is a pain or a boon or something in between when doing API design, that's another matter... –  hyde Mar 29 '13 at 18:35
3  
@hyde: Just because an IDE can automate pointless boilerplate generation doesn't mean that pointless boilerplate is not a pain. –  Michael Shaw Mar 29 '13 at 19:29
1  
@hyde: But the pain isn't removed. The pointless boilerplate is still there, cluttering up the code for no reason. If there is a reason for the boilerplate, what is it? –  Michael Shaw Mar 29 '13 at 20:10
2  
@MichaelShaw If exception is pointless, remove it: ignore the situation or return error value instead. If it is a bug or irrecoverable situation: use unchecked exception. What remains is as important as for example types of parameters, not pointless boilerplate. If it is bad API in existing lib, consider wrapper method/class, using another lib, or just suffering the bad API. –  hyde Mar 29 '13 at 21:28

because with Maybe you can delay handling the error until you actually need the value (which may be a few method calls away)

whereas the checked exception needs to be handled at the call location

the only upside to exceptions is that more information can be passed about why it failed (unless someone develops a MaybeError with a throwable field when it's an error)

share|improve this answer
1  
But I can defer the handling of the checked exception by declaring that my method throws this exception. –  Mad Scientist Mar 29 '13 at 12:51
1  
@MadScientist that only goes up the call stack, while Maybe can go in all directions –  ratchet freak Mar 29 '13 at 12:52
3  
I think you should not confuse Maybe types with handling errors. An exception is used to report an error, an option type is used to represent the result of a partial function. A partial function returning Nothing is not an error. –  Giorgio Mar 29 '13 at 13:29
    
@MadScientist: If a method call returns an "Invalid value" indication, the statement immediately after it can execute. By contrast, if a method throws an exception which is not immediately caught, the statement following the call will be skipped. Letting checked exceptions percolate up the call stack is generally evil (and should not have been the 'easiest' way to deal with them) since there's no way for a caller to tell whether the condition has the meaning expected by the method it called, or whether it represents an unexpected condition which the called method is letting bubble up. –  supercat Mar 13 at 4:14

Your Answer

 
discard

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.