> Although I do it often enough, I'm not a fan of wrapping a checked exception in a RuntimeException or even another checked exception like IOException.
I'm not either. Nor do I like how AssertionError has a constructor that takes an Object rather than specifically a Throwable. But usually (though not always), a better way occurs to me during refactoring. I'm not sure I see the benefit of managed exceptions. Al On Sun, Oct 31, 2021 at 8:22 AM Owen Thomas <owen.paul.tho...@gmail.com> wrote: > 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. >>>> >>> -- Alonso del Arte Author at SmashWords.com <https://www.smashwords.com/profile/view/AlonsoDelarte> Musician at ReverbNation.com <http://www.reverbnation.com/alonsodelarte>
