[compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

[Stefan Bodewig <bo...@apache.org>]

Hi all

there isn't a single option that hasn't at least received two -1s with
eight people indicating their preference. So neither option seems to be
an option that could lead to a compromise.

With this I run out of ideas and will rest my case and not try to find a
generic solution - but rather try to get 1.21 out with no changes in
this area.

That certainly doesn't prevent anybody else from trying to find a
compromise :-)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

[Torsten Curdt <tc...@vafer.org>]

> >> That certainly doesn't prevent anybody else from trying to find a
> >> compromise :-)
>
> > It feels like Optionals could be a compromise.
>
> I must admit I've lost track of the later discussion threads. If you
> mean that we'd return Optional<> results, this would become an entirely
> different API.
>

It certainly does. And I personally don't think it's the best course of
action at this stage - unless someone is eager to work on a new major
version. But if you look for a compromise it seem to be the only one
acceptable to both "camps".


I'd very much like us to get to a compromise that helps our users and
> doesn't force us to randomly fix RuntimeExceptions that slipped through
> overly optimistic parser code.
>

Well, I am fine with the solution you proposed :)

cheers,
Torsten

Re: [compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

[Stefan Bodewig <bo...@apache.org>]

On 2021-07-01, Torsten Curdt wrote:

>> That certainly doesn't prevent anybody else from trying to find a
>> compromise :-)

> It feels like Optionals could be a compromise.

I must admit I've lost track of the later discussion threads. If you
mean that we'd return Optional<> results, this would become an entirely
different API.

I'd very much like us to get to a compromise that helps our users and
doesn't force us to randomly fix RuntimeExceptions that slipped through
overly optimistic parser code.

So if you want to explore the Optionals idea further this would be
great, but I doubt enough people have seen it.

Thanks

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [compress] [Poll Non Result] Dealing with uncaught RuntimeExceptions

[Torsten Curdt <tc...@vafer.org>]

> That certainly doesn't prevent anybody else from trying to find a
> compromise :-)
>

It feels like Optionals could be a compromise.