On 6/29/21 8:08 AM, Stefan Bodewig wrote:
On 2021-06-29, Miguel Munoz wrote:
Catching all RuntimeExceptions and wrapping them in an IOException
looks like the cleanest solution. RuntimeExceptions usually mean bugs,
so if the archive code is throwing them due to a corrupted archive, it
makes
> So ideally Compress will return a CE for parsing errors, and that CE
> should give some context to the error.
> Care must be taken however not to catch every RTE, lest this hide a
coding bug.
+1 for this.
Lee
On Tue, Jun 29, 2021 at 7:57 PM sebb wrote:
> On Tue, 29 Jun 2021 at 12:16, Gary Gr
On 2021-06-29, Miguel Munoz wrote:
> Catching all RuntimeExceptions and wrapping them in an IOException
> looks like the cleanest solution. RuntimeExceptions usually mean bugs,
> so if the archive code is throwing them due to a corrupted archive, it
> makes sense to wrap it in a checked exception.
> Recovery may not be possible for a single archive, but the caller may
> want to process multiple archives.
> (Or potentially try again, if the error was caused by a transient error
> [1])
>
> So ideally Compress will return a CE for parsing errors, and that CE
> should give some context to the er
On Tue, 29 Jun 2021 at 12:16, Gary Gregory wrote:
>
> The best reason to create a new IO exception is if you are going to catch
> it instead of the original and recover differently. I don't think that's
> the case here, there is no "recovery" possible on a corrupted archive. For
> my money, the ex
The best reason to create a new IO exception is if you are going to catch
it instead of the original and recover differently. I don't think that's
the case here, there is no "recovery" possible on a corrupted archive. For
my money, the exception can remain unchecked as it is unrealistic that
recove
Catching all RuntimeExceptions and wrapping them in an IOException looks like
the cleanest solution. RuntimeExceptions usually mean bugs, so if the archive
code is throwing them due to a corrupted archive, it makes sense to wrap it in
a checked exception. I would like to suggest creating a new c
Le lun. 28 juin 2021 à 08:52, Stefan Bodewig a écrit :
>
> On 2021-06-27, Gilles Sadowski wrote:
>
> > Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>
> >> As I said, we can as well document that each method could throw
> >> arbitrary RuntimeExceptions, but I don't believe we can list th
On 2021-06-27, Gilles Sadowski wrote:
> Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>> As I said, we can as well document that each method could throw
>> arbitrary RuntimeExceptions, but I don't believe we can list the kinds
>> of RuntimeExceptions exhaustively
> Why not?
> Listing a
Le dim. 27 juin 2021 à 21:15, Stefan Bodewig a écrit :
>
> On 2021-06-27, Gilles Sadowski wrote:
>
> > Hi.
>
> >> [...]
>
> >> it seemed Gilles was opposed to this idea
>
> > Rather (IIRC) my last comment was that it was your choice as to
> > what the API should look like.
>
> Sorry, I didn't mean
Le dim. 27 juin 2021 à 19:05, Torsten Curdt a écrit :
>> [...]
> > > I'd argue that signaling this problem should be a checked exception.
> > > IMO this provides a clearer contract to the user.
> >
> > It doesn't. The user would have a false sense of security believing so.
> >
>
> I guess I disag
On 2021-06-27, Gilles Sadowski wrote:
> Hi.
>> [...]
>> it seemed Gilles was opposed to this idea
> Rather (IIRC) my last comment was that it was your choice as to
> what the API should look like.
Sorry, I didn't mean to misrepresent your POV.
> My opinion on the matter was along Gary's lines
On 2021-06-27, Gary Gregory wrote:
> Catching all unchecked exceptions (UE) and rethrowing as checked exceptions
> (CE) feels like both a horror show and an exercise in futility, especially
> in order to appease some tool that complains today of one thing which may
> complain differently tomorrow,
Perhaps the key point here is throwing a more specific exception than
RuntimeException? Even if it's a subclass of it. Adding the javadocs
for which exceptions are allowed to be thrown might be sufficient to
cover the DoS attacks.
On Sun, Jun 27, 2021 at 12:05 PM Torsten Curdt wrote:
>
> >
> > >
>
> > Based on that premise we could also just forget about checked exceptions
> > altogether.
>
> As Gary said (as Joshua Bloch said, as many people said), checked
> exceptions are for recoverable errors.
>
Maybe it boils down to the definition of "recoverable".
> Parsing an archive I personall
Checked exceptions are also used when the error isn’t a programmer error.
>From an aesthetic perspective, I prefer the unchecked exceptions unless an
API already established them. Subclassing IOException is fairly common for
example.
On Sun, Jun 27, 2021 at 10:37 Torsten Curdt wrote:
> > Can you
Hi.
Le dim. 27 juin 2021 à 17:37, Torsten Curdt a écrit :
>
> > Can you expand on that - I don't understand the horror or the futility.
>
> >
> > The futility is because it is wrong for the caller to expect that no
> > runtime exception can be thrown.
> >
>
> Based on that premise we could also j
> Can you expand on that - I don't understand the horror or the futility.
>
> The futility is because it is wrong for the caller to expect that no
> runtime exception can be thrown.
>
Based on that premise we could also just forget about checked exceptions
altogether.
I think the distinction is
On Sun, 27 Jun 2021 at 15:01, sebb wrote:
>
> On Sun, 27 Jun 2021 at 14:06, Torsten Curdt wrote:
> >
> > > feels like both a horror show and an exercise in futility
> >
> >
> > Can you expand on that - I don't understand the horror or the futility.
> >
> > It certainly is a bit of code smell - bu
Hi.
> [...]
> it seemed Gilles was opposed to this idea
Rather (IIRC) my last comment was that it was your choice as to
what the API should look like.
My opinion on the matter was along Gary's lines (which is J. Bloch's
rationale provided in "Effective Java").
Indeed I personally would indeed *n
On Sun, 27 Jun 2021 at 14:06, Torsten Curdt wrote:
>
> > feels like both a horror show and an exercise in futility
>
>
> Can you expand on that - I don't understand the horror or the futility.
>
> It certainly is a bit of code smell - but only because there is no quick
> way to harden the implemen
> feels like both a horror show and an exercise in futility
Can you expand on that - I don't understand the horror or the futility.
It certainly is a bit of code smell - but only because there is no quick
way to harden the implementations.
But I rather have a clear and stable API and fix the th
Catching all unchecked exceptions (UE) and rethrowing as checked exceptions
(CE) feels like both a horror show and an exercise in futility, especially
in order to appease some tool that complains today of one thing which may
complain differently tomorrow, I really don't like that idea on paper.
Le
+1 for 2)
In [Imaging] we do something similar, but it was easier because there were many
methods that were already doing it (throwing ImageReadException or
ImageWriteException).
Bruno
On Sunday, 27 June 2021, 11:03:31 pm NZST, Stefan Bodewig
wrote:
Hi
I'd like to get closure o
I personally think that we should look at it from the point of view of the
API consumer.
What would they want to happen in case of an error reading an archive?
IMO an IOException.
How we get to that exception on the implementation side is another matter.
If we could check all conditions and throw
Hi
I'd like to get closure on which approach we want to take.
When we read a broken archive it may trigger arbitrary RuntimeExceptions
because we are not explicitly checking for each and every sizuation
where a bounds check could fail, a negative size is sent to a classlib
method that then throws
26 matches
Mail list logo
