Adding my two cents here...
It's very important to me as a user and developer to have informative
errors. If I use compress in my application and a raw NPE or out of bounds
exception flies out of the code with little to no context and makes it out
to the end user, then I am going to be getting a c
> [...]
> > One is "sorry, this is an invalid archive" while the other is "something
> > > went wrong reading the archive - printStackTrace". If that distinction is
> > > not important to you - so be it. To me that's a big difference.
> >
> > Never said such a thing.
> >
>
> Not sure what "thing" y
> > So IllegalArgumentException is not from the early Java days?
>
> It is, so what?
> It's the exception I use 99% of the time (to signal failed precondition)?
> It's a runtime exception.
>
When I quote standard exceptions you said:
"if you quote design decisions that date back from the early Ja
Le jeu. 1 juil. 2021 à 11:31, Torsten Curdt a écrit :
>
> > I'm not sure what you refer to exactly,
>
>
> The various links from
>
> https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html
>
> or even
>
> https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
>
>
> > but
> I'm not sure what you refer to exactly,
The various links from
https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html
or even
https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
> but I noted already that not all
> references are equal, especially if you quot
Le jeu. 1 juil. 2021 à 02:27, Torsten Curdt a écrit :
>
> >
> > "If there is runtime exception there is a bug in the code"
> >
> > I don't think that's correct because IllegalArgumentException is a
> > RuntimeException.
>
>
> I have a hard time following that causality. The way I've seen this
> ex
>
> "If there is runtime exception there is a bug in the code"
>
> I don't think that's correct because IllegalArgumentException is a
> RuntimeException.
I have a hard time following that causality. The way I've seen this
exception used mainly is in case of program errors, not in case of input
va
"If there is runtime exception there is a bug in the code"
I don't think that's correct because IllegalArgumentException is a
RuntimeException. See
https://docs.oracle.com/javase/8/docs/api/java/lang/IllegalArgumentException.html
Gary
On Wed, Jun 30, 2021, 16:50 Torsten Curdt wrote:
> >
> > It
>
> It is not the job of commons-compress to stop you from using a
> corrupt archive. If you choose to do so, then ...
>
I don't think that's what it is.
That would be more like getting an exception and continuing walking through
the archive.
If there is a parse exception there is a bug in the in
Am 30.06.21 um 14:41 schrieb Gary Gregory:
On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig wrote:
Hi
I'm sorry, but I'm unable to see what would or would not work for the
people who chimed in. Short of calling for a vote, lets try with a poll
that could show whether there is some sort of so
On Tue, Jun 29, 2021 at 10:24 PM Stefan Bodewig wrote:
> (4) don't catch RuntimeExceptions at all, just document broken archives
> can cause arbitrary RuntimeExceptions and code that tries to read
> archives from untrusted sources is expected to deal with them
> itself.
Strongly in f
On 2021-06-29, Stefan Bodewig wrote:
> Options raised during the thread:
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
+1
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOException (possibly a subc
On Tue, Jun 29, 2021 at 4:24 PM Stefan Bodewig wrote:
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybod
Le mer. 30 juin 2021 à 11:55, PeterLee a écrit :
>
> > (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> >subclass) and throw the IOException
>
> -1
>
> I agree with sebb about this option - this may accidentally convert a bug
> into
> something else.
>
> > (2) catch o
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
>subclass) and throw the IOException
-1
I agree with sebb about this option - this may accidentally convert a bug
into
something else.
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOExcept
Le mer. 30 juin 2021 à 02:32, Bernd Eckenfels a écrit :
>
> I vote for the subclass of IOException - if you care about handling broken
> archives you would catch it,
Yes, but you can catch a runtime exception all the same.
An application that doesn't want to terminate abruptly must catch
all exc
:33:16 AM
To: Commons Developers List
Subject: Re: [compress] [Poll] Dealing with uncaught RuntimeExceptions
Le mar. 29 juin 2021 à 22:24, Stefan Bodewig a écrit :
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Sh
Le mar. 29 juin 2021 à 22:24, Stefan Bodewig a écrit :
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybo
> (1) catch all RuntimeExceptions, wrap them in an IOException (possibly a
> subclass) and throw the IOException
>
+0
> (2) catch only a subset of all RuntimeExceptions, wrap them in an
> IOException (possibly a subclass) and throw the IOException - allow
> the remaining RuntimeExce
On Tue, 29 Jun 2021 at 21:24, Stefan Bodewig wrote:
>
> Hi
>
> I'm sorry, but I'm unable to see what would or would not work for the
> people who chimed in. Short of calling for a vote, lets try with a poll
> that could show whether there is some sort of solution that is
> acceptable to everybody.
Hi
I'm sorry, but I'm unable to see what would or would not work for the
people who chimed in. Short of calling for a vote, lets try with a poll
that could show whether there is some sort of solution that is
acceptable to everybody.
Please use +1 to mean "I like this option", +0 to mean "the opti
21 matches
Mail list logo
