Exception transparency - lone throws (no checked exceptions)

[Jesse Kuhnert]

I think the fundamental question here is whether or not this is within
the scope of this project?

Nothing irks me more than being told I must catch this or that
exception which I'm sure many if not all people might agree, but it
exists already. We could come out of this with an entirely new
language if we followed the path along to the end right?

You are making lots of "quotes" but I'm unclear as to whether you are
personally responsible for the success of the project other than some
vague references to "speaking for the common man, the general
developer".

You don't speak for me, and I imagine - after having used joda many
times finding that the API is downright frustrating and nonsensical at
times - do you really speak for the common developer as much as your
inflated ego would like to think. What's a period or interval or
duration? They all sound the same to me. wtf?.. Indeed.

On Saturday, June 12, 2010, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 11 June 2010 18:59, Brian Goetz <brian.goetz at oracle.com> wrote:
>>  (This is a solution to the
>> problem of exception transparency much as arson is a solution to the problem
>> of cockroaches.)
> Hmmm. I might argue that the same analogy applies to the strawman
> (ie.overkill). Neither analogy gets us anywhere.
>
>
> My aim is to avoid the horrific syntax that exception abstraction
> requires. If someone can show a sensible approach at the syntax level
> for function types and methods that need to be transparent, then I
> have no objection to the basic direction of the strawman. I simply
> don't believe such a syntax exists.
>
> Also, I would re-emphasise, as others have, that if all exceptions in
> Java were unchecked, then we would not be having this discussion. With
> respect to both parties, has Oracle simply accepted Neal's definition
> of "exception transparency" (ie "exception abstraction") without going
> back to the original problem?
>
> To summarise, this thread contrasts two options:
> 1) Strawman. Lots of extra syntax. Fully retains the power of checked
> exceptions.
> 2) Lone throws. Little extra syntax. Reduces the use of checked exceptions.
> Reinier has presented another approach which also has merit.
>
> My sole goal in this project is to ensure that the end result is
> usable by typical Java developers (a combination of semantics and
> syntax). Variance mark 2 (both semantics and syntax) must be avoided
> at all costs.
>
>
>> Besides the points raised here, I could easily imagine a world where
>> developers who don't like checked exception just decorated every method with
>> "throws".  I don't know if that is the intent of the proposal or simply a
>> side-effect, but it is (in our view) some pretty serious collateral damage.
> It is not the intent of the author, no. (I do dislike checked
> exceptions, but I fully acknowledge that many like them, and they are
> a feature of Java).
>
> If some people chose to make use of the feature, then that is their
> decision. Given that the vast majority of existing open source
> libraries current wrap checked in unchecked, I suspect it would be
> very widely adopted. So, yes, choosing this proposal should be done
> with a full awareness that it will be used to reduce the role of
> checked exceptions generally. Some might view this as "serious
> collateral damage" - others might view this as a "separate language
> feature that has benefits in P.Lambda". The truth is somewhere in the
> middle.
>
> Finally, as many have commented - there is nothing new here. Escaped
> checked exceptions already happen, and are very hard to catch today.
> Given the increasing integration of languages other than Java
> (something I believe was being actively supported by Sun/Oracle), the
> escaped exception issue is only getting worse. Being honest about it
> would be a service to the whole Java community separate to Lambda.
>
> (Actually, a Project Coin feature to allow the coder to catch escaped
> checked exceptions would have been a good submission on its own)
>
> Plus, would "lone throws" not help some of the API parts of invoke
> dynamic where methods might throw exceptions?
>
> Occasionally its time to think the unthinkable ;-)
>
> Stephen
>
>