Perhaps these type of exceptions can be called "managed" exceptions. Two syllables instead of the monosyllabic "checked" might draw interest to the possibility that a slightly more complicated mechanism can make things easier for the developer. I don't know.
On Sun, 31 Oct 2021 at 23:07, Owen Thomas <owen.paul.tho...@gmail.com> wrote: > On Sun, 31 Oct 2021 at 18:24, Emilian Bold <emilian.b...@gmail.com> wrote: > >> 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... >> > > Thank you for trying Emilian. Sometimes I find it hard to speak directly. > Hopefully you'll find some sense in what I'm trying to talk about in this > reply. :) > > Please also note that I speak from a position of ignorance about Java > modules. I hope you can fill in the blanks with your own understanding of > Java modules which I assume is better than mine. > > >> For eg. not sure what "ignored" means. Does it behave like a Runtime >> Exception? Or is it just not thrown? >> > > I think it fair that javac should not compile your code if you attempt to > catch or if you declare that any method throws an exception that is > "ignored". Perhaps you may think that is too harsh, but I'm less than eager > to accept anything more accommodating at this point in time until I hear a > compelling reason for why this might be better. > > >> Same with the other 2 options. >> > > Okay. <cracks knuckles> > > Imagine this scenario. Hopefully, this use case describes what happens > when an exception that extends this CheckedException class is "ignored". If > you get the use-case I am describing here, you can probably imagine what > might happen in other scenarios. > > So, you are developing a library that depends on another library. This > other library declares in a module descriptor that a particular exception > is "thrown". It has to do this because this exception extends > CheckedException, and at least one method in this module declares that it > throws this exception. > > You're in charge of the module descriptors in your library. In your > library, you have a module governed by a descriptor which says that the > exception thrown from the module defined above is "ignored". You have to > care about this because at least one of the methods defined in your module > calls at least one of the methods defined in the module above. When you > call any method declared within the above defined module from your module, > your calling method cannot either catch this ignored exception in your > code, nor declare that it throws this exception. > > Importantly, I think that the checked behaviour of such an exception has > been preserved. Modules defined by others that call one or more methods > defined in yours would likewise have to do something with this ignored > exception just as you have done. A developer using your library would have > to declare in their module descriptor what they are going to do with the > exception that you have ignored if they are going to call any methods of > your module: either to declare that they are "ignored" or "caught"... > another use case. > > So, you have "ignored" the fact that a method you call throws a particular > extension of the class CheckedException. Your methods cannot catch, or > declare that they throw this exception because you said in your module's > descriptor that you wanted this concern abstracted away for you. You have, > however, passed this concern onto anyone who might use your module. Others > are free to do with their module as you have done with yours, but they > still have to do something to address the fact that this checked exception > you have elected to ignore has been passed through your module to theirs. > > Owen. > > PS: > *A small, and I think favourable twist in the behaviour of checked > exceptions expressed through this mechanism is that one might be able to, > say, have Object.equals() throw these type of checked exceptions. This > would perhaps slightly and temporarily modify the signature for > Object.equals() which has been overridden in some module where a particular > checked exception was "thrown" until the exception was handled somewhere in > another dependent module where the exception was "caught". I can't at this > moment see why this would be a problem; I see it as something I would like.* > > PPS: Perhaps, if another developer's library implements a mechanism called > directly from Thread.run(), any "ignored" exception will just behave like > an unchecked exception. Perhaps however, it would be more in-keeping with > the original intentions of the checked exception mechanism that a compiler > error would be issued, and hence I like this latter scenario better. > > > >> >> 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. >>> >>
