A) A possibility is to rewrite those methods to return a Runnable or similar that is later applied (well, an Option<Runnable> or an Either<Failure, Runnable>). That way you are no longer ignoring the return values as a matter of course.
Perhaps a better way there is to pass in some kind of error case handler. I don't know the correct answer though. B) I usually use Option as a null replacement rather than as an error case. Its disadvantage as an error case is that it doesn't say where it came from. You can use Either<Failure, X> for that, where Failure is whatever you want it to be, but probably a good rule is that if you think you might need to know where it came from you're talking about a software bug rather than something a program can recover from, so an unchecked exception would suffice. C) I'm repeating myself a bit, but here's the approximate set of rules I use: 1. If there's a software bug or I'm too lazy to think about the error case at the moment, an unchecked exception will happen and that will be logged/reported. 2. If the method has void as its return type and can't easily be transformed so that callers normally consume its result, I'll use a checked exception. 3. If the method has something other than void as its return type I'll use Option/Either or whatever seems appropriate. It's not uncommon to invent your own types similar to Option, e.g., I had one named UserResponse that would either hold a String containing the user's answer to a question, or would represent that the user had entered nothing, or that the user had cancelled the dialog. data UserResponse = Response s | Empty | Cancelled -- to express it in Haskell. On Thu, Mar 24, 2011 at 12:03 PM, Reinier Zwitserloot <[email protected]>wrote: > error-via-return-value is far inferior to anything else as a complete > solution to what checked/unchecked exceptions are trying to do. Here are the > problems with it: > > (A) For any method that would ordinarily return void, this boils down to > C-style "return error codes". I pray I don't have to explain why this is far > far worse compared to exceptions (of either checked or unchecked variety). > > (B) Where you can get away with returning maybes/options, you're making it > much harder for code to decide to defer the handling of this error condition > to something up the chain. It's also infectious - if as part of doing your > thing you could run into errors, then you have to turn whatever you return > into an Option/Maybe guard as well. At some point virtually every method > returns option/maybe. > > (C) You don't solve the problem of "where do we draw the line?" - when does > an exception become sufficiently unlikely that you're better off making it a > checked exception? The same question applies to: When do we return Option > and when do we not? You're not solving any problems here. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
