On Fri, 29 Oct 2021 at 11:48, Owen Thomas
wrote:
> I say the following. Have an abstract checked exception class in the Java
> SE API. Call it, say, Checked*Managed*Exception. Descendents of this
> class behave like any other checked exception, with perhaps a few caveats
> [covered in the
On Tue, 2 Nov 2021 at 06:35, Emilian Bold 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
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
> 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
On Mon, 1 Nov 2021 at 09:51, Alonso Del Arte
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
> 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
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
On Sun, 31 Oct 2021 at 18:24, Emilian Bold 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
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...
For eg. not sure what "ignored" means. Does it behave like a Runtime
Exception? Or is it just not thrown?
Same with the other 2 options.
I think you could do a byte code
On Sat, 30 Oct 2021 at 17:53, Owen Thomas
wrote:
> If checked exceptions could be selectively suppressed like this, then
> perhaps I could override Object.equals() with a throws clause that threw
> any exception [that extends CheckedException] I chose. Developers of
> libraries that were
If checked exceptions could be selectively suppressed like this, then
perhaps I could override Object.equals() with a throws clause that threw
any exception I chose. Developers of libraries that were dependent on mine
could "ignore" this if that's what they wanted.
Thinking about it now, I can't
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 think this solution is ugly, bug prone, and can be avoided
through what I believe are relatively minor and unobtrusive enhancements
given in my
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
13 matches
Mail list logo
