3 ms·
Alas the java community disagrees, and this collective decision should be carefully analyzed and respected Because it represents the conclusion, despite ample
by AtlasBarfed 2y ago
Alas the java community disagrees, and this collective decision should be carefully analyzed and respected
Because it represents the conclusion, despite ample guidance and dogma by Sun, of the mass market millions of java programmers, resulting in second generation (groovy) and third generation (kotlin) JVM languages that dropped checked exceptions entirely.
It might be the languages error handling syntax (try catch) led to ugly code (and I always contended that local vars declared in a try block should have been lexically visible to catch blocks)
It might be that javas std lib had a poorly designed exception pattern. It could be that implementing exception classes was annoying.
But I think there is other reasons. In large scale enterprise development, checked exceptions start to pollute and permeate code that otherwise doesn't want excessive type system exposure from the linked /imported libraries.
What results even with checked exception lite is that "exception barriers" that catch all exceptions and repackage them are established at major system boundaries. Checked exception enforcement would just create more of these IMO.
The wet dream of checked exceptions was encouraging APIs that had a thorough understanding of all the error conditions and could use checked exceptions to enforce a good handling recovery API usage pattern
In reality it's the halting problem: too hard to predict l all the error conditions (that isn't really known until version 3 or 4 of the API and by then the API signatures are set.
Let's look at something simple like json serialization. Yeah there's a litany of parse errors and the like.
But there is ALSO the issue of disparate sources of the json. File errors from file sources. Network errors from streamed communication channels. Your general stream or file interface isn't that simple of an abstraction when source specific errors raise their heads.
The abstraction become leaky real real fast.
- Yeroc 2y agoI'm one of the naysayers as an experienced Java developer that supports checked exceptions. I find the move to runtime exceptions very disheartening though I will say that in a world dominated by web applications with a clear request/response cycle it's very easy for the container/application to implement a high-level error-handler so I think this skews people's sense of the value proposition of checked exceptions. I've done a fair bit of work over the years writing daemons of various types and having checked IO exceptions among others has been a lifesaver. I also feel that vilifying use of generic exceptions (IOException, SQLException) in favour of implementation-specific exceptions was a mistake. If instead, we had encouraged a smaller set of mostly platform-defined exceptions I believe people would have found the exception "noise" to be lesser. While there are cases where a custom exception sub-type can be useful, in many cases they are not. I agree with the grandparent comment that we may have been better off without runtime exceptions at all, leaving us with simply checked exceptions and errors.
- AtlasBarfed 2y agoChecked exceptions were an ideal. From a halcyon Valhalla of fallen unix programmers trying to impart their wisdom to the ignorant masses. I too would like to live in this world. However, while I don't have specific exceptions at the tip of my tongue, Even sun failed in many of their jdk apis to produce a good checked exception design.