I don't understand your proposal. You are trying to explain it in an almost formal way but I don't know what it means...
For eg. not sure what "ignored" means. Does it behave like a Runtime Exception? Or is it just not thrown? Same with the other 2 options. I think you could do a byte code processor and tweak checked exceptions but of course you would change signatures. --emi vin., 29 oct. 2021, 03:48 Owen Thomas <owen.paul.tho...@gmail.com> a scris: > G'day. > > Upon seeing some recent emails from this group expressing a somewhat > philosophical tone about how the evolving landscape of paradigms in > software development may be putting a strain on Java, I just wish to put > some comments that others might find interesting down about how a specific > Java feature, namely checked exceptions, can be improved so that again, > Java perhaps can show how to do something well enough that other languages > might try and copy it. > > I say the following. Have an abstract checked exception class in the Java > SE API. Call it, say, CheckedException. Descendents of this class behave > like any other checked exception, with perhaps a few caveats explained in > this email. > > The build script of a deployable artifact (an application or library, but > in this case, probably a library explains the situation more clearly) > somehow indicates that this deployable artifact (hereon referred to as a > library) can declare that descendents of CheckedExceptions (never the > CheckedException class itself) are: > > 1. thrown: A more specific descendent of a checked exception under > this clause occurs in the throws clause of a method that is exposed to > libraries that are dependent on this one. > > 2. caught: A more specific descendent of a checked exception under > this clause occurs in the catch block of a method that calls a method from > a library on which this one depends. > > 3. ignored: Neither of the above scenarios occurs. *However, methods > in this library that call methods that throw a descendent of a checked > exception under this clause do not themselves explicitly declare that they > throw or catch and deal with the given checked exception*. > > If a library declares that it throws or ignores a descendent of a > CheckedException, in its build script or other deployment descriptor, then > any dependent library must either declare that that CheckedException is > thrown, caught, or ignored. > > The emphasis above is used to underscore the utility that my suggestion is > trying to convey. I think that with perhaps a few tweaks, this is a > flexible suggestion. Although I do not (not yet perhaps... I just need a > compelling reason to) know much about Java modules, this system of > selectively dealing with checked exceptions appears as a very good > candidate for expression there. > > These are just suggestions and I put them out there because someone with > some clout in shaping the future of the Java SE API might think these > suggestions are worth considering further. Happy to share and perhaps to > talk about it here if others share a similar interest. > > Have a great day. :) > > Owen. >
