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
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
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
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
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
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
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
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
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
> 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 -
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
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
> 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
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.
+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
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
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
19 matches
Mail list logo
