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. >> >
