[Silhouette]

Exceptions in general FORCE a developer to deal with the problem.

There are good arguments in favour of exceptions, but I don't think this is one of them. If Java has taught us anything, it is that trying to force someone to handle exceptions just causes a lot of code that says:

    catch (Exception e)
    {
        // silently ignore e
    }

[suresk]

Actually, the correct comment for an empty catch block is:

// This should never happen.

(Until it does)

I have mixed feelings about checked exceptions. They seem like a great idea in theory - if there are known error states, then making them explicitly known and forcing the consumer to acknowledge them in some way seems reasonable. In practice, a lot of the time the only response to a checked exception is "let it propagate up - there isn't anything useful I can do", which leads to extra code and can be annoying.

Even though I don't have quite the negative feelings toward them others do, if I were involved in designing a new language today, I'd probably vote against including them. It would possibly be nice if a method could explicitly declare which exceptions it was likely to throw, and then an IDE or static analysis tool could use those to aid consumers of the API, without forcing them to deal with every single one.

Interestingly enough, I view Scala's Option construct as being somewhat similar - forcing the consumer to acknowledge that a particular call could return a null value - but it doesn't seem to provoke the same negative visceral reactions that checked exceptions do.

[Quarrelsome]

Sure you can do that but the programmer is FORCED to make the choice to write that. Also the code _looks_ wrong like that.

Furthermore if the dev just wraps the entire process in that silent catch then the lion doesn't get poked!