On Wed, Oct 1, 2014 at 7:24 AM, Bruno Medeiros via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> > What has failed is not the concept of checked exceptions per se, but > mostly, the failure of Java programmers to use checked exceptions > effectively, and properly design their code around this paradigm. > > This. I have seen many java programs (and their programmers) fail utterly at using exceptions. Like OO, the design of the system has to leverage it properly, and there are places where people can easily get tripped up - but when used well, can be immensely useful. Error handling is part of an API, and exceptions are error handling, so should be considered when designing API. Checked exceptions are a language-supported way to do this. For those that consider checked exceptions a failure: what other feature(s) would work instead? NB: If you see "throws Exception" in java code chances are the code is broken, same as if you see "catch (Exception" - this tells you nothing about the exception that happened, and hence you can do nothing with it. So you either swallow (and silently break in many cases) or rethrow (and break for things you needn't have). As mentioned, the standard way to avoid this is to have a parent exception type appropriate to the abstraction in the API, and throw subtypes in the implementation. Among other things, this means you can change the implementation to throw different exceptions without breaking any users (who will already be catching the parent exception). Adding/modifying a throws clause is an API-breaking change, so should be avoided however easy it is in the IDE. (Yes, I'm biased to writing libraries consumed by others) NNB: Retrofitting a program to use proper exception handling is much harder than it is to design it the right way from scratch. I'm going to compare to OO again: don't consider OO broken because people use inheritance when they want ownership, and it is painful to fix later.