2 ms·

I disagree pretty strongly with the idea that: "there is no way of telling that [a method] may throw an exception". If you want reliable code, you have assume

I disagree pretty strongly with the idea that: "there is no way of telling that [a method] may throw an exception". If you want reliable code, you have assume that _every_ method can throw an exception. (Or, assume that methods that don't throw are the exception, like C++ 'noexcept') This also ignores the fact that Java considers exceptions part of the method signature. Without opening the whole can of worms as to whether that was a good or a bad design decision, it seems a little perverse to talk about Java, but then choose a language (Scala) that deliberately hides the exceptions, and then complain they are hidden.

noelwelsh 12y ago
The implicit context here is that Underscore is a Scala consultancy, and thus the language under discussion is Scala. Many Scala developers come from a Java background (or indeed, most other languages that are not statically typed functional languages) and thus use Java idioms in Scala. "Java without the semi-colons" is the phrase used for this kind of code in the Scala community. As for assuming that every method can throw an exception, yes in Scala and Java and most other languages you do have to have some top level exception handler. However the goal of modern type systems is to have the types an accurate reflection of effects of the method, so that the type system can catch errors for you. This post is about how you can do that.