Exception transparency - lone throws (no checked exceptions)

[Jesse Kuhnert]

btw, I could do this all day. Bring on your Reiners / Howards /
Stephens. It's time for a reckoning. Being a java developer does not
make you a language designer. Learn your place.

On Sat, Jun 12, 2010 at 8:52 PM, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
> 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
>>
>>
>