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