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
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
+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
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
> 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
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
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 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
> 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
It's hard to tell what the actual change is below with all of the
formatting / cosmetic changes mixed it, but AFAICT there is no sync
control to ensure consistency or currency of the stats reported. Some
note in javadoc or somewhere should be added to make it clear that stats
may not accurately
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
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
I will update Javadoc and add inline comments.
Gary
On Sun, Jun 27, 2021, 11:49 Phil Steitz wrote:
> It's hard to tell what the actual change is below with all of the
> formatting / cosmetic changes mixed it, but AFAICT there is no sync
> control to ensure consistency or currency of the stats
>
> > 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
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:
>
> >
> > >
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,
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
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
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
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
20 matches
Mail list logo