On 25 March 2011 13:04, JodaStephen <[email protected]> wrote: > My objection to checked exceptions is I suspect slightly different to > some. > > In theory, they are a great idea. An extension to the static type > system (as such, its surprising that all exceptions in Scala aren't > checked!). The theory is that you write your code and force the user > of your API to actually think about the errors that might occur. >
Not possible. Throws clauses are erased, just as collection elements are, and are only checked by the compiler and not the runtime (hence the ability to even write @sneakyThrows or to "chuck" them without requiring a RuntimeException wrapper) Checked exceptions are more of a shadow type system, not so much extending it as running alongside it. Essentially, they offer a sideband return channel. Given the availability of "Either", true pattern matching, and monadic comprehension in Scala, there's no need for this kind of hackery. An exception (or any other type) can simply be offered up as a possible alternative return value via the usual return mechanism. Unchecked exceptions can then be quite correctly reserved for things that are... well... exceptional! > However, after 15 years, all the evidence is that this fails the > usability requirement. The mass of developers (right up to Sun) are > clearly unable to *use* this feature in a useful and meaningful way. > Thats all - the entire total of the argument for me. > > Despite year after year of discussion, conference talks, forum > discussions, code reviews and much more, the Java community hasn't > managed to produce an agreed and successful use of the feature. > Examples in this case include all the catch and ignore, catch and > rethrow, adding of "Exception" to every single throws clause, > disagreement on how exception hierarchies should be structured, > arguments over whether a particular exception should be checked or > unchecked, and many more. > > Thus, no matter how good a feature is in theory, how useful it might > be, how its "just a matter of training" or "using it properly", the > absence of successful usage and the presence of unsuccessful usage > tells you all you need to know - its a failure. Usability is the only > criteria that matters. > > Stephen > > -- > 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. > > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
