On Tue, 2 Nov 2021 at 06:35, Emilian Bold <emilian.b...@gmail.com> wrote:
> It looks to me that the JVM doesn't have the concept of checked > exceptions, only Java has. So, it may be valid bytecode to just rip out > checked exception from the method signatures. New compilations, targeting a > modified JAR, will not complain about the checked exception. At runtime > they will be handled by the normal try-catch chain. > > Which is to say, bytecode processing may be sufficient. No need for > language-wide changes. > > --emi > I think I understand that checked exceptions are only relevant to the Java compiler; the "checking" is only performed by the compiler and the JVM doesn't care about whether a calling method throws or catches checked exceptions. This is, as I understand, why a language like Kotlin can omit the feature from its compiler and call Java methods that throw checked exceptions without problems. So, I think some small and contained changes to the runtime might be appropriate, but the changes would not be too invasive. The changes would be relevant only in the circumstance where a Java module descriptor specifies which managed exceptions are thrown, caught or ignored and so these changes would be backwards compatible. I now think I prefer this "managed" term in place of "checked" because the runtime environment doesn't care about checked exceptions, and I don't think it a good idea to change this behaviour. Maybe the feature I am describing would also be deemed fit to be appropriated by others like Kotlin. If a feature like this can garner broader support, I might even make it official and look at how to apply through the JCP. Owen. > On Mon, Nov 1, 2021 at 9:23 PM Alonso Del Arte <alonso.dela...@gmail.com> > wrote: > >> > Might it be good to have a way to indicate to others that your module >> can guarantee that checked exceptions have not been buried inside unchecked >> ones? >> >> Okay, that might be good to know. We can certainly write that in the >> Javadoc, but without a system like what you're proposing we would be on the >> honor system. >> >> As you might know, Scala inventor Martin Odersky wrote the Java 1.3 >> compiler. Java was not evolving as fast as he wanted it to. He put a lot of >> things into Scala that Java eventually adopted later, and some that will be >> added to future versions of Java. >> >> But his approach was to make all exceptions unchecked, though you can add >> an @throws annotation for the sake of interoperability with Java. >> Clearly that's something Java will never adopt.Your idea of managed >> exceptions seems likelier to be added. >> >> Suppose that Java 19 adds managed exceptions. What changes would an IDE >> like NetBeans have to make in response to that? >> >> Al >> >> On Sun, Oct 31, 2021 at 11:22 PM Owen Thomas <owen.paul.tho...@gmail.com> >> wrote: >> >>> >>> >>> On Mon, 1 Nov 2021 at 09:51, Alonso Del Arte <alonso.dela...@gmail.com> >>> wrote: >>> >>>> > 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. >>>> >>> >>> Might it be good to have a way to indicate to others that your module >>> can guarantee that checked exceptions have not been buried inside unchecked >>> ones? >>> >>> I'm wondering if perhaps it might be good to generate a compile error in >>> code that threw anything other than the type of managed exception that was >>> indicated to be thrown in an associated module descriptor? >>> >>> Owen. >>> >> >> >> -- >> Alonso del Arte >> Author at SmashWords.com >> <https://www.smashwords.com/profile/view/AlonsoDelarte> >> Musician at ReverbNation.com <http://www.reverbnation.com/alonsodelarte> >> >
