Groups > comp.lang.java.programmer > #33580 > unrolled thread

Java Checked Exception is BAD!

Started by	boxzou@gmail.com
First post	2016-02-04 07:18 -0800
Last post	2016-02-19 03:43 -0800
Articles	20 on this page of 122 — 17 participants

Back to article view | Back to comp.lang.java.programmer

  Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 07:18 -0800
    Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 08:15 -0800
      Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-04 17:57 +0100
        Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 10:09 -0800
          Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-04 21:01 +0100
            Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 12:14 -0800
            Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-04 15:16 -0500
              Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-04 21:37 +0100
                Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 13:08 -0800
                  Re: Java Checked Exception is BAD! 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-04 21:16 +0000
                    Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 13:28 -0800
                    Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-04 23:11 +0000
                      Re: Java Checked Exception is BAD! a.laforgia@gmail.com - 2016-02-05 04:21 -0800
                        Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-05 13:07 +0000
                Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-04 18:04 -0500
                  Re: Java Checked Exception is BAD! Gene Wirchenko <genew@telus.net> - 2016-02-05 11:40 -0800
            Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-04 23:22 +0100
            Re: Java Checked Exception is BAD! ruben <ceo@iran.gov> - 2016-02-15 11:45 +0000
        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 11:57 -0800
          Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-04 21:07 +0100
      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 11:10 -0800
        Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-04 11:28 -0800
          Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 11:33 -0800
            Re: Java Checked Exception is BAD! 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-04 21:08 +0000
            Re: Java Checked Exception is BAD! Lew <lewbloch@gmail.com> - 2016-02-04 16:09 -0800
    Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-04 12:00 -0500
    Re: Java Checked Exception is BAD! Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-02-04 19:28 +0100
      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 11:15 -0800
        Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-04 14:51 -0500
    Re: Java Checked Exception is BAD! 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-04 21:07 +0000
      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 14:36 -0800
        Re: Java Checked Exception is BAD! a.laforgia@gmail.com - 2016-02-05 05:28 -0800
    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 15:31 -0800
      Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-05 08:20 -0500
        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-05 08:25 -0800
          Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-05 08:47 -0800
            Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-05 16:09 -0800
              Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-06 08:38 -0500
                Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-06 14:13 +0000
                  Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-06 15:23 +0100
                    Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-07 14:49 +0100
                      Re: Java Checked Exceptions Robert Klemme <shortcutter@googlemail.com> - 2016-02-07 21:55 +0100
                        Re: Java Checked Exceptions boxzou@gmail.com - 2016-02-07 14:39 -0800
                          Re: Java Checked Exceptions Robert Klemme <shortcutter@googlemail.com> - 2016-02-08 13:30 +0100
                            Re: Java Checked Exceptions boxzou@gmail.com - 2016-02-08 06:14 -0800
                              Re: Java Checked Exceptions Robert Klemme <shortcutter@googlemail.com> - 2016-02-08 20:55 +0100
                              Re: Java Checked Exceptions Lew <lewbloch@gmail.com> - 2016-02-08 16:06 -0800
                                Re: Java Checked Exceptions boxzou@gmail.com - 2016-02-08 18:38 -0800
                                  Re: Java Checked Exceptions Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-09 12:15 +0000
                                    Re: Java Checked Exceptions boxzou@gmail.com - 2016-02-09 04:59 -0800
                                  Re: Java Checked Exceptions Lew <lewbloch@gmail.com> - 2016-02-10 12:13 -0800
                                    Re: Java Checked Exceptions boxzou@gmail.com - 2016-02-10 19:00 -0800
                                      Re: Java Checked Exceptions Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-11 12:18 +0000
                                    Re: Java Checked Exceptions leif.roar@dimnakorr.com - 2016-02-11 04:43 -0600
                      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:34 -0800
                    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:11 -0800
                      Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-07 23:19 +0000
                        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 15:42 -0800
                  Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-06 09:43 -0500
                    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:14 -0800
                      Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-08 09:22 -0500
                        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 11:01 -0800
                        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 11:08 -0800
                        Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-08 22:02 +0100
                  Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:09 -0800
                    Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-07 23:29 +0000
                      Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-08 21:49 +0100
                        Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-08 17:23 -0500
                          Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 18:46 -0800
                            Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-09 08:21 +0100
                              Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-09 04:58 -0800
                                Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-09 08:17 -0500
                                  Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-09 07:57 -0800
                                    Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-10 02:37 +0100
                                      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-10 18:58 -0800
                                        Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-11 08:13 -0500
                                        Re: Java Checked Exception is BAD! Lew <lewbloch@gmail.com> - 2016-02-11 14:02 -0800
                                          Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-11 16:41 -0800
                                Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-10 02:31 +0100
                                  Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-10 18:47 -0800
                            Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-09 12:26 +0000
                              Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-09 04:57 -0800
                                Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-09 18:27 +0000
                Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 20:19 -0800
              Re: Java Checked Exception is BAD! Robert Klemme <shortcutter@googlemail.com> - 2016-02-06 16:01 +0100
                Re: Java Checked Exception is BAD! 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-06 15:10 +0000
                  Re: Java Checked Exception is BAD! Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-02-06 17:59 -0800
                    Re: Java Checked Exception is BAD! 4ndre4 <4ndre4@4ndre4.com.invalid> - 2016-02-07 09:34 +0000
                    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:23 -0800
                  Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 20:52 -0800
                  Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 21:13 -0800
                Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-07 14:19 -0800
                  Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-07 23:42 +0000
                  Re: Java Checked Exception is BAD! Robert Klemme <shortcutter@googlemail.com> - 2016-02-08 13:17 +0100
                    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 04:39 -0800
                      Re: Java Checked Exception is BAD! Lew <lewbloch@gmail.com> - 2016-02-08 16:05 -0800
                        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 18:35 -0800
                          Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 19:10 -0800
                          Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-08 19:12 -0800
                        Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-11 16:37 +0100
                          Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-11 12:00 -0500
                            Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-11 19:01 +0100
                              Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-11 20:32 +0100
                              Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-11 15:20 -0500
                                Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-11 23:53 +0100
                                  Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-11 18:21 -0500
                                  Re: Java Checked Exception is BAD! Lew <lewbloch@gmail.com> - 2016-02-11 15:45 -0800
                                    Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-12 01:19 +0100
                                      Re: Java Checked Exception is BAD! Lew <lewbloch@gmail.com> - 2016-02-11 19:18 -0800
                                        Re: Java Checked Exception is BAD! Sebastian <news@seyweiler.dyndns.org> - 2016-02-12 08:31 +0100
                                          Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-12 15:33 +0100
                                    Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-12 15:41 +0100
                                      Re: Java Checked Exception is BAD! Silvio <silvio@internet.com> - 2016-02-12 15:42 +0100
                    Re: Java Checked Exception is BAD! Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-08 21:19 +0000
          Re: Java Checked Exception is BAD! Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-02-05 13:00 -0500
    Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 15:51 -0800
      Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 15:59 -0800
        Re: Java Checked Exception is BAD! boxzou@gmail.com - 2016-02-04 16:03 -0800
      Re: Java Checked Exception is BAD! Eric Douglas <e.d.programmer@gmail.com> - 2016-02-05 05:33 -0800
    Re: Java Checked Exception is BAD! Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2016-02-04 21:05 -0800
    Re: Java Checked Exception is BAD! ynseo <yeori.seo@gmail.com> - 2016-02-08 01:05 -0800
    Re: Java Checked Exception is BAD! Sebastian <sebastian.millies@softwareag.com> - 2016-02-19 03:43 -0800

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →

#33776

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2016-02-11 12:00 -0500
Message-ID	<n9iei6$sbr$1@dont-email.me>
In reply to	#33775

On 2/11/2016 10:37 AM, Silvio wrote:
> [...]
> I am curious what you think of the way checked exceptions and lambdas
> interfere. Do you think they got this right?
>
> In my opinion they chose the least painful option, be it far from painless.
>
> To be honest I think the single biggest thing hampering lambda
> usefulness is the "effectively final" restriction on local variables.
> But together with that I think the way checked exceptions interfere with
> lambdas have made them the crippled nephew of real closures like they
> exist in other languages, among which Scala.
>
> I think the former was a poor lambda design decision. The latter was
> inevitable because of the existence of checked exceptions.

     Wrong, on several counts.

     1) There is nothing that prevents a lambda expression from throwing
a checked exception.  Nor an unchecked exception, for that matter.  A
lambda expression can throw any kind of Throwable it wants to, so long
as the interface it implements allows it.

     2) The various interfaces used with stream pipelines (Predicate,
Collector, BiConsumer, and so on) describe methods that do not throw
checked exceptions.  If you wanted to roll up your sleeves and get down
and dirty with StreamSupport and so on, I imagine you could invent your
own pipeline stages and throw any exceptions you like.

     3) Although lambda expressions are often convenient when writing
stream pipelines, they are not essential to the task.  For any pipeline
using lambda expressions, you could write an equivalent using anonymous
classes -- or using ordinary named classes, for that matter.

     4) Stream pipelines interact badly with exceptions (which may be a
reason why the standard interfaces declare none), but it has nothing
to do with whether the exceptions are checked or unchecked.  See up-
thread for a demonstration I posted a few days ago, illustrating a
Bad Thing that can happen when a pipeline stage throws RuntimeException.

     5) ... and my illustration could just as well have used anonymous
classes instead of lambdas.

     The problems with streams and exceptions have nothing to do with
whether the exceptions are checked, and have nothing to do with whether
they originate from lambda expression bodies.

     Aside from that, we're in perfect agreement.  ;-)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33777

From	Silvio <silvio@internet.com>
Date	2016-02-11 19:01 +0100
Message-ID	<56bccc91$0$23792$e4fe514c@news.xs4all.nl>
In reply to	#33776

On 02/11/2016 06:00 PM, Eric Sosman wrote:
> On 2/11/2016 10:37 AM, Silvio wrote:
>> [...]
>> I am curious what you think of the way checked exceptions and lambdas
>> interfere. Do you think they got this right?
>>
>> In my opinion they chose the least painful option, be it far from
>> painless.
>>
>> To be honest I think the single biggest thing hampering lambda
>> usefulness is the "effectively final" restriction on local variables.
>> But together with that I think the way checked exceptions interfere with
>> lambdas have made them the crippled nephew of real closures like they
>> exist in other languages, among which Scala.
>>
>> I think the former was a poor lambda design decision. The latter was
>> inevitable because of the existence of checked exceptions.
>
>      Wrong, on several counts.
>
>      1) There is nothing that prevents a lambda expression from throwing
> a checked exception.  Nor an unchecked exception, for that matter.  A
> lambda expression can throw any kind of Throwable it wants to, so long
> as the interface it implements allows it.
>

Right, so the context in which a lambda is used determines what checked 
exceptions it can throw, thanks for confirming that.
That means it will either impose a static limit or just allow 
everything. Either way the allowed exceptions will have to be handled at 
the call site, regardless of what the lambda it lexically encloses 
actually throws.

The only way to get this at the level of normal Java code logic would be 
to allow the method that takes the lambda parameter express that it will 
throw whatever the actual lambda throws so the compiler can enforce 
checked exceptions at the call site. Since there could be multiple 
lambda parameters or exceptions thrown by the method itself that would 
call for some kind of set logic syntax to express what exceptions a 
method might throw but in theory it would be possible.

But since lambdas are second class citizens and we need a declared 
interface for the parameter type allowed exceptions are always 
statically limited at the method level, regardless of the call site.

>      2) The various interfaces used with stream pipelines (Predicate,
> Collector, BiConsumer, and so on) describe methods that do not throw
> checked exceptions.  If you wanted to roll up your sleeves and get down
> and dirty with StreamSupport and so on, I imagine you could invent your
> own pipeline stages and throw any exceptions you like.

Kind of beats the purpose of having the pipelines in the standard 
library doesn't it? Of course you can roll your own and I might even 
have to roll multiple versions depending on the particular exception my 
lambdas might want to throw. No thanks.

>
>      3) Although lambda expressions are often convenient when writing
> stream pipelines, they are not essential to the task.  For any pipeline
> using lambda expressions, you could write an equivalent using anonymous
> classes -- or using ordinary named classes, for that matter.
>

Of course you can. What is your point except underlining that the added 
value of lambdas over anonymous classes is reduced precisely because of 
limitations raised by checked exceptions?

>      4) Stream pipelines interact badly with exceptions (which may be a
> reason why the standard interfaces declare none), but it has nothing
> to do with whether the exceptions are checked or unchecked.  See up-
> thread for a demonstration I posted a few days ago, illustrating a
> Bad Thing that can happen when a pipeline stage throws RuntimeException.
>
>      5) ... and my illustration could just as well have used anonymous
> classes instead of lambdas.
>
>      The problems with streams and exceptions have nothing to do with
> whether the exceptions are checked, and have nothing to do with whether
> they originate from lambda expression bodies.
>
>      Aside from that, we're in perfect agreement.  ;-)
>

I was not at all limiting this to streams. They are great but there are 
much more places where lambdas can be used to create abstractions.

Given some additional syntactical sugar lambdas could allow a library to 
add all kinds of abstractions that would make call sites with enclosed 
lambdas blend in perfectly with the rest of the Java code. But because 
of checked exceptions declared at the method level the compiler will 
enforce logical boundaries inside the code demanding exception types to 
be handled although static code analysis could prove they can never be 
thrown.

I realize that lambdas did not exist when checked exceptions where put 
into the language. And I also agree that it is not at all black or 
white. Checked exceptions have advantages as well as disadvantages. What 
weighs stronger is partly a matter of taste. But the way they limit 
lambdas most definitely weighs against them.

[toc] | [prev] | [next] | [standalone]

#33778

From	Sebastian <news@seyweiler.dyndns.org>
Date	2016-02-11 20:32 +0100
Message-ID	<n9inkv$a0o$1@news.albasani.net>
In reply to	#33777

Am 11.02.2016 19:01, schrieb Silvio:

[snip]

> Right, so the context in which a lambda is used determines what checked
> exceptions it can throw

[snip]

> I was not at all limiting this to streams. They are great but there are
> much more places where lambdas can be used to create abstractions.

[snip]

> I realize that lambdas did not exist when checked exceptions where put
> into the language. And I also agree that it is not at all black or
> white. Checked exceptions have advantages as well as disadvantages. What
> weighs stronger is partly a matter of taste. But the way they limit
> lambdas most definitely weighs against them.

I think that is true, to some extent, but not to a very large extent. On 
the one hand, when you take a pure view of lambdas as functions, they 
have no business throwing exceptions in the first place, checked or 
unchecked. That is mostly taken the view by the Streams API. The Stream 
API provides some means that can function as an alternative for 
exceptions, such as Optional (and there are libraries that provide for 
more possibilities).

I don't find this view too limiting. Indeed, I sympathize with it. This 
is partly also because of the difficulties that are raised by exceptions 
(checked or unchecked) in parallel processing which have been discussed 
in this thread and been demonstrated by Eric.

CompletableFuture takes another view (lambdas may be used to provide 
tasks, which definitely aren't functions), and at the same time also 
provides means to deal with exceptions (CompletionException and the 
various flavors of exceptionally/whenComplete/handle). These means are a 
bit clumsy sometimes, but some additional utilities to address the weak 
points will be in Java 9.

That leaves the cases Silvio mentions where the compiler wants to 
enforce exception handling because it's not smart enough, as in the 
example I posted earlier in this topic. These definitely are painful, 
and they very much underline the fact that a library author should not 
hastily impose his view on what exceptions his clients should be 
required to handle on said clients. Libraries may come to be used in 
unexpected contexts, while clairvoyance remains as difficult as always.

These cases are mostly in legacy libararies, some of them in the JDK 
itself. I am in agrrement with Brian Goetz (can't find the reference at 
the moment, sorry, but it was somewhere in the Expert Group discussions 
for Project Lambda) in expecting that library code will evolve to throw 
fewer checked exceptions, and at the same time not believing they should 
be thrown completely out of application code.

I regret that the tone in this part of the conversation has started to 
veer back towards the acrimonious. Please try to stay civil, guys.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#33779

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2016-02-11 15:20 -0500
Message-ID	<n9iq9g$f95$1@dont-email.me>
In reply to	#33777

On 2/11/2016 1:01 PM, Silvio wrote:
> On 02/11/2016 06:00 PM, Eric Sosman wrote:
>> On 2/11/2016 10:37 AM, Silvio wrote:
>>> [...]
>>> I am curious what you think of the way checked exceptions and lambdas
>>> interfere. Do you think they got this right?
>>>
>>> In my opinion they chose the least painful option, be it far from
>>> painless.
>>>
>>> To be honest I think the single biggest thing hampering lambda
>>> usefulness is the "effectively final" restriction on local variables.
>>> But together with that I think the way checked exceptions interfere with
>>> lambdas have made them the crippled nephew of real closures like they
>>> exist in other languages, among which Scala.
>>>
>>> I think the former was a poor lambda design decision. The latter was
>>> inevitable because of the existence of checked exceptions.
>>
>>      Wrong, on several counts.
>>
>>      1) There is nothing that prevents a lambda expression from throwing
>> a checked exception.  Nor an unchecked exception, for that matter.  A
>> lambda expression can throw any kind of Throwable it wants to, so long
>> as the interface it implements allows it.
>>
>
> Right, so the context in which a lambda is used determines what checked
> exceptions it can throw, thanks for confirming that.

     It seems clearer to me to say that the lambda expression creates
an implementation of some functional interface, and the interface
governs what exceptions can be thrown -- just as it governs what
parameters the implemented method takes and what type it returns.

> That means it will either impose a static limit or just allow
> everything. Either way the allowed exceptions will have to be handled at
> the call site, regardless of what the lambda it lexically encloses
> actually throws.

     I'm not sure I follow this.  A `throws' clause, wherever you find
one, is "static" in the sense that it can't be changed at run time, but
what's unusual about that?  That's how Java has always been, even
before lambdas came along.  (Or danced onto the scene, if you misspell
them as "lambadas.")  Also, it's always been the case that exceptions
are processed by the nested set of `try' blocks enclosing the `throw';
again, lambda expressions have not changed this.  So, I'm at a loss
to understand what you find strange about the current state of affairs.

> The only way to get this at the level of normal Java code logic would be
> to allow the method that takes the lambda parameter express that it will
> throw whatever the actual lambda throws so the compiler can enforce
> checked exceptions at the call site. Since there could be multiple
> lambda parameters or exceptions thrown by the method itself that would
> call for some kind of set logic syntax to express what exceptions a
> method might throw but in theory it would be possible.

     Again, lambda expressions just produce classes that implement
interfaces (and yield references to methods of those classes).  If
the interface declares its abstract method with no `throws', the
lambda body must not throw an IOException.  But if the interface
says `throws IOException' you're fine.

     An interface can say `throws Exception' or even `throws Throwable',
but it seems to me those are cop-outs.

> But since lambdas are second class citizens and we need a declared
> interface for the parameter type allowed exceptions are always
> statically limited at the method level, regardless of the call site.

     I do not understand what you mean by "second class" here.  As far
as I can see, the only "new" thing about lambda expressions (beyond
the syntax) is the fact that they yield method references, something
Java didn't offer until recently.  These are almost equivalent:

	Set<String> newWay = new TreeSet<>((p,q) ->
	    p.toLowerCase().compareTo(q.toLowerCase));

	Set<String> oldWay = new TreeSet<>(new Comparator() {
	    @Override
	    public int compare(String p, String q) {
	        return p.toLowerCase().compareto(q.toLowerCase());
	    }
	});

>>      3) Although lambda expressions are often convenient when writing
>> stream pipelines, they are not essential to the task.  For any pipeline
>> using lambda expressions, you could write an equivalent using anonymous
>> classes -- or using ordinary named classes, for that matter.
>
> Of course you can. What is your point except underlining that the added
> value of lambdas over anonymous classes is reduced precisely because of
> limitations raised by checked exceptions?

     There is no reduction, not as far as I can see, and certainly
not because of checked exceptions.  The interface describes what (if
any) exceptions are permitted, and the lambda expression is no more
(or less) limited than an ordinary class would be.

> [...]
> I realize that lambdas did not exist when checked exceptions where put
> into the language. And I also agree that it is not at all black or
> white. Checked exceptions have advantages as well as disadvantages. What
> weighs stronger is partly a matter of taste. But the way they limit
> lambdas most definitely weighs against them.

     What additional "limit" do checked exceptions place on lambda
expressions that they do not also place on ordinary classes that
implement the same interface?  I'm not seeing it.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33781

From	Silvio <silvio@internet.com>
Date	2016-02-11 23:53 +0100
Message-ID	<56bd10d2$0$23750$e4fe514c@news.xs4all.nl>
In reply to	#33779

On 02/11/2016 09:20 PM, Eric Sosman wrote:
>
>      Again, lambda expressions just produce classes that implement
> interfaces (and yield references to methods of those classes).  If
> the interface declares its abstract method with no `throws', the
> lambda body must not throw an IOException.  But if the interface
> says `throws IOException' you're fine.
>
>      An interface can say `throws Exception' or even `throws Throwable',
> but it seems to me those are cop-outs.
>
>      I do not understand what you mean by "second class" here.  As far
> as I can see, the only "new" thing about lambda expressions (beyond
> the syntax) is the fact that they yield method references, something
> Java didn't offer until recently.  These are almost equivalent:
>
>      Set<String> newWay = new TreeSet<>((p,q) ->
>          p.toLowerCase().compareTo(q.toLowerCase));
>
>      Set<String> oldWay = new TreeSet<>(new Comparator() {
>          @Override
>          public int compare(String p, String q) {
>              return p.toLowerCase().compareto(q.toLowerCase());
>          }
>      });
>

Yes, you are totally correct. That is how lambdas are defined in Java.

I call them second class citizens here because they have no inherent 
type. Their type is deduced from the expected type at the location they 
occur so they are coerced into an instance of a synthetic class 
compatible with that expected type. That indeed reduces them to little 
more than a shorthand for local classes. That line of reasoning makes 
the limitation that a lambda can not modify local state and must conform 
to the normal checked exception rules seem no more than logical.

I suspect part of the reason for doing it this way was the desire to 
make lambdas compatible with classes and methods in the existing runtime 
library without changing them. Like being able to use a lambda wherever 
a Runnable value is expected.

To me it seems like they came up with the brilliant idea to add actual 
closures to Java and in the end settled on what we now call lambdas. 
Perhaps because it would take too much effort to do actual closures, 
perhaps because of backward compatibility issues, perhaps because they 
feared the Java world would consider them too foreign, perhaps because 
they just did not fit in nicely with things like checked exceptions 
without adding substantial complexity to the existing language.

>
>      There is no reduction, not as far as I can see, and certainly
> not because of checked exceptions.  The interface describes what (if
> any) exceptions are permitted, and the lambda expression is no more
> (or less) limited than an ordinary class would be.
>
>> [...]
>> I realize that lambdas did not exist when checked exceptions where put
>> into the language. And I also agree that it is not at all black or
>> white. Checked exceptions have advantages as well as disadvantages. What
>> weighs stronger is partly a matter of taste. But the way they limit
>> lambdas most definitely weighs against them.
>
>      What additional "limit" do checked exceptions place on lambda
> expressions that they do not also place on ordinary classes that
> implement the same interface?  I'm not seeing it.
>

As long as you look at a lambda as no more than a shorthand for an 
ordinary class that is to be expected. Look at what can be done with 
closures in other languages, Scala for example, and you may see my point.

And you would be right that such is not impossible with checked 
exceptions. I just do not think any language should want to have so 
complex a type system as would be required to make that work.

[toc] | [prev] | [next] | [standalone]

#33782

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2016-02-11 18:21 -0500
Message-ID	<n9j4rq$r1t$1@dont-email.me>
In reply to	#33781

On 2/11/2016 5:53 PM, Silvio wrote:
> On 02/11/2016 09:20 PM, Eric Sosman wrote:
>> [... Silvio called lambdas "second class citizens" ...]
>>
>>      I do not understand what you mean by "second class" here.  As far
>> as I can see, the only "new" thing about lambda expressions (beyond
>> the syntax) is the fact that they yield method references, something
>> Java didn't offer until recently.[...]
>
> Yes, you are totally correct. That is how lambdas are defined in Java.
>
> I call them second class citizens here because they have no inherent
> type. Their type is deduced from the expected type at the location they
> occur so they are coerced into an instance of a synthetic class
> compatible with that expected type. That indeed reduces them to little
> more than a shorthand for local classes. That line of reasoning makes
> the limitation that a lambda can not modify local state and must conform
> to the normal checked exception rules seem no more than logical.

     Okay.  I don't understand why you use the demeaning "second
class" label, though.  The meaning of the diamond notation (sometimes
miscalled the "diamond operator") is also deduced from context rather
than by explicit declaration; does that make it "second class" as
well?  Or how about the context-dependent decision to auto-(un)-box or not?

     Heck, what about the compiler's choice of access level for a
implied constructor?  Governed by context, yes?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33783

From	Lew <lewbloch@gmail.com>
Date	2016-02-11 15:45 -0800
Message-ID	<9e042cbd-0f26-406a-8d98-8abcc4bdc7e4@googlegroups.com>
In reply to	#33781

On Thursday, February 11, 2016 at 2:53:47 PM UTC-8, Silvio wrote:
> On 02/11/2016 09:20 PM, Eric Sosman wrote:
> >
> >      Again, lambda expressions just produce classes that implement
> > interfaces (and yield references to methods of those classes).  If
> > the interface declares its abstract method with no `throws', the
> > lambda body must not throw an IOException.  But if the interface
> > says `throws IOException' you're fine.
> >
> >      An interface can say `throws Exception' or even `throws Throwable',
> > but it seems to me those are cop-outs.
> >
> >      I do not understand what you mean by "second class" here.  As far
> > as I can see, the only "new" thing about lambda expressions (beyond
> > the syntax) is the fact that they yield method references, something
> > Java didn't offer until recently.  These are almost equivalent:
> >
> >      Set<String> newWay = new TreeSet<>((p,q) ->
> >          p.toLowerCase().compareTo(q.toLowerCase));
> >
> >      Set<String> oldWay = new TreeSet<>(new Comparator() {
> >          @Override
> >          public int compare(String p, String q) {
> >              return p.toLowerCase().compareto(q.toLowerCase());
> >          }
> >      });
> >
> 
> Yes, you are totally correct. That is how lambdas are defined in Java.
> 
> I call them second class citizens here because they have no inherent 
> type. Their type is deduced from the expected type at the location they 
> occur so they are coerced into an instance of a synthetic class 
> compatible with that expected type. That indeed reduces them to little 
> more than a shorthand for local classes. That line of reasoning makes 
> the limitation that a lambda can not modify local state and must conform 
> to the normal checked exception rules seem no more than logical.
> 
> I suspect part of the reason for doing it this way was the desire to 
> make lambdas compatible with classes and methods in the existing runtime 
> library without changing them. Like being able to use a lambda wherever 
> a Runnable value is expected.
> 
> To me it seems like they came up with the brilliant idea to add actual 
> closures to Java and in the end settled on what we now call lambdas. 

It was a wellspring of demand from the programmer community that sparked the addition.

At no point really did the Java Godparents actually consider full first-class functions, or closures. 

> Perhaps because it would take too much effort to do actual closures, 
> perhaps because of backward compatibility issues, perhaps because they 

The stated reasons were backward compatibility and to minimize the ramp-up for developers.

> feared the Java world would consider them too foreign, perhaps because 

Nonsense. The "Java world" was all agog over closures, and wanted them so badly they forced Java to change.

I watched it happen, in these very forums.

> they just did not fit in nicely with things like checked exceptions 
> without adding substantial complexity to the existing language.
> 
> >
> >      There is no reduction, not as far as I can see, and certainly
> > not because of checked exceptions.  The interface describes what (if
> > any) exceptions are permitted, and the lambda expression is no more
> > (or less) limited than an ordinary class would be.
> >
> >> [...]
> >> I realize that lambdas did not exist when checked exceptions where put
> >> into the language. And I also agree that it is not at all black or
> >> white. Checked exceptions have advantages as well as disadvantages. What
> >> weighs stronger is partly a matter of taste. But the way they limit
> >> lambdas most definitely weighs against them.

Perhaps one should not declare checked exceptions in the overridden method of lambdas, then.

> >      What additional "limit" do checked exceptions place on lambda
> > expressions that they do not also place on ordinary classes that
> > implement the same interface?  I'm not seeing it.
> >
> 
> As long as you look at a lambda as no more than a shorthand for an 
> ordinary class that is to be expected. Look at what can be done with 
> closures in other languages, Scala for example, and you may see my point.

Other languages are beside the point. Java never claimed to have closures in full. Lambdas were billed initially as a notational convenience for SAM (Single-Abstract-Method) interfaces (after competing with other ideas). Since then, what with streams and the :: notation, they've become a rather powerful and useful construct. Far more so than I expected when it was first discussed.

> And you would be right that such is not impossible with checked 
> exceptions. I just do not think any language should want to have so 
> complex a type system as would be required to make that work.

Checked exceptions, like most code idioms, are subject to abuse, especially by people who don't understand exceptions or the rationale for including them in a method signature. It is not mandatory to use them in your API - many APIs use only runtime exceptions. Of course, those also carry risk, due to the very fact that they are not part of the method signature.

Exceptions generally, not just checked exceptions, pose issues for anonymous classes and lambdas generally. We just have to be smart about understanding our programming language, and how we use it.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33785

From	Silvio <silvio@internet.com>
Date	2016-02-12 01:19 +0100
Message-ID	<56bd24f7$0$23827$e4fe514c@news.xs4all.nl>
In reply to	#33783

On 02/12/2016 12:45 AM, Lew wrote:
>
> It was a wellspring of demand from the programmer community that sparked the addition.
>
> At no point really did the Java Godparents actually consider full first-class functions, or closures.
>
>> Perhaps because it would take too much effort to do actual closures,
>> perhaps because of backward compatibility issues, perhaps because they
>
> The stated reasons were backward compatibility and to minimize the ramp-up for developers.
>
>> feared the Java world would consider them too foreign, perhaps because
>
> Nonsense. The "Java world" was all agog over closures, and wanted them so badly they forced Java to change.
>
> I watched it happen, in these very forums.
>
>
> Perhaps one should not declare checked exceptions in the overridden method of lambdas, then.
>

That is no solution because it limits what the lambda can throw, if I 
understand you correctly.

>
> Other languages are beside the point. Java never claimed to have closures in full. Lambdas were billed initially as a notational convenience for SAM (Single-Abstract-Method) interfaces (after competing with other ideas). Since then, what with streams and the :: notation, they've become a rather powerful and useful construct. Far more so than I expected when it was first discussed.
>
>
> Checked exceptions, like most code idioms, are subject to abuse, especially by people who don't understand exceptions or the rationale for including them in a method signature. It is not mandatory to use them in your API - many APIs use only runtime exceptions. Of course, those also carry risk, due to the very fact that they are not part of the method signature.
>
> Exceptions generally, not just checked exceptions, pose issues for anonymous classes and lambdas generally. We just have to be smart about understanding our programming language, and how we use it.
>

I agree with part of what you say although I was under the impression 
only a small part of the Java world was all over the subject back then. 
At the time I too followed the same forums and studied the proposed 
solutions but I must say that I was nonetheless surprised and definitely 
disappointed with the final outcome. There where more than a few people 
back then who suggested a more ambitious form of closures, both 
syntactically and semantically. And I found the motivations for the 
final decisions made rather vague. But perhaps that was just my lack of 
understanding.

I disagree that other languages are beside the point. It was quite a 
move for Java the language and a perfect opportunity to make the step 
forward a bigger one. In retrospect I find they where too conservative 
and the outcome has made Java less attractive in comparison to 
alternative languages than it could have been. You see it differently.

[toc] | [prev] | [next] | [standalone]

#33787

From	Lew <lewbloch@gmail.com>
Date	2016-02-11 19:18 -0800
Message-ID	<d9706e35-32c3-456f-b4fb-7c4247069241@googlegroups.com>
In reply to	#33785

On Thursday, February 11, 2016 at 4:19:11 PM UTC-8, Silvio wrote:
> On 02/12/2016 12:45 AM, Lew wrote:
> >
> > It was a wellspring of demand from the programmer community that sparked the addition.
> >
> > At no point really did the Java Godparents actually consider full first-class functions, or closures.
> >
> >> Perhaps because it would take too much effort to do actual closures,
> >> perhaps because of backward compatibility issues, perhaps because they
> >
> > The stated reasons were backward compatibility and to minimize the ramp-up for developers.
> >
> >> feared the Java world would consider them too foreign, perhaps because
> >
> > Nonsense. The "Java world" was all agog over closures, and wanted them so badly they forced Java to change.
> >
> > I watched it happen, in these very forums.
> >
> >
> > Perhaps one should not declare checked exceptions in the overridden method of lambdas, then.
> >
> 
> That is no solution because it limits what the lambda can throw, if I 
> understand you correctly.

I don't mean deny it from the language, just throwing out an idiomatic approach. I don't really have a good answer for this.

> > Other languages are beside the point. Java never claimed to have closures in full. Lambdas were billed initially as a notational convenience for SAM (Single-Abstract-Method) interfaces (after competing with other ideas). Since then, what with streams and the :: notation, they've become a rather powerful and useful construct. Far more so than I expected when it was first discussed.
> >
> >
> > Checked exceptions, like most code idioms, are subject to abuse, especially by people who don't understand exceptions or the rationale for including them in a method signature. It is not mandatory to use them in your API - many APIs use only runtime exceptions. Of course, those also carry risk, due to the very fact that they are not part of the method signature.
> >
> > Exceptions generally, not just checked exceptions, pose issues for anonymous classes and lambdas generally. We just have to be smart about understanding our programming language, and how we use it.
> >
> 
> I agree with part of what you say although I was under the impression 
> only a small part of the Java world was all over the subject back then. 

Maybe you are right. It may be that that part was vocal and made an impression on me.

> At the time I too followed the same forums and studied the proposed 
> solutions but I must say that I was nonetheless surprised and definitely 
> disappointed with the final outcome. There where more than a few people 
> back then who suggested a more ambitious form of closures, both 

True. And the Powers That Be scaled it back for reasons couched as feasibility and compatibility.

> syntactically and semantically. And I found the motivations for the 
> final decisions made rather vague. But perhaps that was just my lack of 
> understanding.

And I may be projecting conclusions and assumptions into my memories.

> I disagree that other languages are beside the point. It was quite a 
> move for Java the language and a perfect opportunity to make the step 
> forward a bigger one. In retrospect I find they where too conservative 
> and the outcome has made Java less attractive in comparison to 
> alternative languages than it could have been. You see it differently.

I didn't mean it quite the way I made it sound. You are correct that it might not make Java seem as attractive as other languages. I just meant to say that we live with the limitations of the language at hand, and when programming in Java its limitations are just a part of the landscape. While its lambdas may not match the power of Scala's closures, you are working with a conceptually simpler syntax as a result. This empowers more workaday programmers to get the job done. Java's weakness for the adept functional programmer may be an organizational strength in the world that pays salaries.

I agree that Java's functional approach is stripped down compared to functional languages. For good or ill, this was intentional and documented in the moment. For good or ill, the tradeoff was acknowledged.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33788

From	Sebastian <news@seyweiler.dyndns.org>
Date	2016-02-12 08:31 +0100
Message-ID	<n9k1nv$pvc$1@news.albasani.net>
In reply to	#33787

Am 12.02.2016 04:18, schrieb Lew:

>
> I didn't mean it quite the way I made it sound. You are correct that it might not make Java seem as attractive as other languages. I just meant to say that we live with the limitations of the language at hand, and when programming in Java its limitations are just a part of the landscape. While its lambdas may not match the power of Scala's closures, you are working with a conceptually simpler syntax as a result. This empowers more workaday programmers to get the job done. Java's weakness for the adept functional programmer may be an organizational strength in the world that pays salaries.
>

I hope that didn't come out quite as you meant it as well. I'd resent 
any implication that people who use Java in their daily work are just 
too dumb to grasp functional programming. I don't think functional 
programming is any "harder" than, say, OO programming, imperative style 
programming, Horn clause logic, what not. It's just a question of 
education, i. e. good teaching, but not of inherent difficulty. 
Java-programmers-are-stupid had nothing to do with the decisions taken 
in Project Lambda. But it has always been clear that Java was not to be 
made into a functional programming language.

Nevertheless, ideas from FP can give one new and useful perspectives on 
how to solve some problems in Java. And it can also give one a better 
feeling for what Java's limitations are in that respect. Anyone can 
understand enough of the basics of FP and acquire the skill of reading 
an FP language like Haskell and start experimenting.

Well, this remark has been entirely off-topic for this conversation. I 
apologize,

Sebastian

[toc] | [prev] | [next] | [standalone]

#33791

From	Silvio <silvio@internet.com>
Date	2016-02-12 15:33 +0100
Message-ID	<56bded1f$0$23758$e4fe514c@news.xs4all.nl>
In reply to	#33788

On 02/12/2016 08:31 AM, Sebastian wrote:
> Am 12.02.2016 04:18, schrieb Lew:
>
>>
>> I didn't mean it quite the way I made it sound. You are correct that
>> it might not make Java seem as attractive as other languages. I just
>> meant to say that we live with the limitations of the language at
>> hand, and when programming in Java its limitations are just a part of
>> the landscape. While its lambdas may not match the power of Scala's
>> closures, you are working with a conceptually simpler syntax as a
>> result. This empowers more workaday programmers to get the job done.
>> Java's weakness for the adept functional programmer may be an
>> organizational strength in the world that pays salaries.
>>
>
> I hope that didn't come out quite as you meant it as well. I'd resent
> any implication that people who use Java in their daily work are just
> too dumb to grasp functional programming. I don't think functional
> programming is any "harder" than, say, OO programming, imperative style
> programming, Horn clause logic, what not. It's just a question of
> education, i. e. good teaching, but not of inherent difficulty.
> Java-programmers-are-stupid had nothing to do with the decisions taken
> in Project Lambda. But it has always been clear that Java was not to be
> made into a functional programming language.
>
> Nevertheless, ideas from FP can give one new and useful perspectives on
> how to solve some problems in Java. And it can also give one a better
> feeling for what Java's limitations are in that respect. Anyone can
> understand enough of the basics of FP and acquire the skill of reading
> an FP language like Haskell and start experimenting.
>
> Well, this remark has been entirely off-topic for this conversation. I
> apologize,
>
> Sebastian
>
>
>

No apologies needed.

Actually I did not read his response that way. I am sure Lew did not 
mean to put down Java programmers in any way. And he is right in saying 
that a language can not be everything to everyone. With power comes 
complexity and not desiring complexity does not imply inability to grasp it.

I switched to Scala for new applications years ago, must have been at 
least five years by now. At the same time I still do quite some 
maintenance on applications that where written in Java before that so I 
think I have a pretty current view on both languages.

As much as I prefer Scala over Java I certainly see the trade-offs made. 
The language is much more complex and I no longer really buy into the 
idea of using a subset of the language as a better Java. If you do not 
need or can not really leverage the extra power then you should not want 
the extra complexity.

As always it really depends on the target audience. I like to ponder 
about what might have been. Lew is right in saying that leads to 
nothing. Still...

[toc] | [prev] | [next] | [standalone]

#33792

From	Silvio <silvio@internet.com>
Date	2016-02-12 15:41 +0100
Message-ID	<56bdef04$0$23758$e4fe514c@news.xs4all.nl>
In reply to	#33783

On 02/12/2016 01:18 AM, Stefan Ram wrote:
> Lew <lewbloch@gmail.com> writes:
>> At no point really did the Java Godparents actually consider full first-class functions, or closures.
>
>        »Guy Steele wrote:
>
>        Actually, the prototype implementation *did* allow non-final
>        variables to be referenced from within inner classes.  There was
>        an outcry from *users*, complaining that they did not want this!«
>
> http://madbean.com/2003/mb2003-49/
>

Yes, I remember that as if it happened yesterday. And to be honest at 
the time it felt like a debating trick to me. I was under the impression 
a small group of people was following the discussion and an a-priori 
outcry seemed very unlikely to me. But note: that was my personal 
feeling so I may very well be wrong (that would be the first time).

Allowing non-final access has quite some implications. In effect it 
means that the accessed variables have to be "lifted" to the heap by 
wrapping them in a mutable object. Although autoboxing also brings 
implicit wrapping into the language I understand the hesitations. In 
retrospect I am sure that would have been a positive trade-off but 
again: that is just me.

[toc] | [prev] | [next] | [standalone]

#33793

From	Silvio <silvio@internet.com>
Date	2016-02-12 15:42 +0100
Message-ID	<56bdef5a$0$23758$e4fe514c@news.xs4all.nl>
In reply to	#33792

On 02/12/2016 03:41 PM, Silvio wrote:
> On 02/12/2016 01:18 AM, Stefan Ram wrote:
>> Lew <lewbloch@gmail.com> writes:
>>> At no point really did the Java Godparents actually consider full
>>> first-class functions, or closures.
>>
>>        »Guy Steele wrote:
>>
>>        Actually, the prototype implementation *did* allow non-final
>>        variables to be referenced from within inner classes.  There was
>>        an outcry from *users*, complaining that they did not want this!«
>>
>> http://madbean.com/2003/mb2003-49/
>>
>
> Yes, I remember that as if it happened yesterday. And to be honest at
> the time it felt like a debating trick to me. I was under the impression
> a small group of people was following the discussion and an a-priori
> outcry seemed very unlikely to me. But note: that was my personal
> feeling so I may very well be wrong (that would be the first time).
>
> Allowing non-final access has quite some implications. In effect it
> means that the accessed variables have to be "lifted" to the heap by
> wrapping them in a mutable object. Although autoboxing also brings
> implicit wrapping into the language I understand the hesitations. In
> retrospect I am sure that would have been a positive trade-off but
> again: that is just me.
>

Sorry for not following your link first: in a sense I repeated what was 
already said there.

[toc] | [prev] | [next] | [standalone]

#33689

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2016-02-08 21:19 +0000
Message-ID	<n9b0pd$k9q$1@dont-email.me>
In reply to	#33668

On Mon, 08 Feb 2016 13:17:54 +0100, Robert Klemme wrote:

> For example: whether unwrapping needs to be done manually is completely
> dependent on the use case.  When logging, the logging framework usually
> takes care of that (or rather implementation in Throwable).  When
> catching it is often sufficient to know why the immediately called
> module failed without digging into the details of underlying layers. The
> case where you would have to extract one or more levels of root cause
> exceptions is an extremely rare case (I cannot remember having come
> across that need even once).
>
About the only case where I've found it useful is diagnosing SQL 
exceptions, but that applies regardless of whether the SQL client is 
Java, C or any other language.

The SQL specification states than in general the exception you get is the 
head of a chain of one or more exceptions and its frequently useful to 
look at the whole chain to understand when caused the SQL query to fail 
and why. If your client is written in C it the ODBC driver's error 
processor returns a diagnostic string for the exception at the head of 
the list and the next error code or zero. The processor is called 
repeatedly until the chain has been scanned. If the client is written in 
Java, JDBC throws the initial SQLexception , which contains a link to the 
next SQLexception or null. Again, you scan the chain until a null link is 
found. Following and displaying error text from the whole chain is so 
frequently useful that I tend to do it as a matter of course.

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33619

From	Eric Sosman <esosman@comcast-dot-net.invalid>
Date	2016-02-05 13:00 -0500
Message-ID	<n92nrk$5dp$1@dont-email.me>
In reply to	#33617

On 2/5/2016 11:25 AM, boxzou@gmail.com wrote:
> On Friday, 5 February 2016 08:21:19 UTC-5, Eric Sosman  wrote:
>> On 2/4/2016 6:31 PM, b...@gmail.com wrote:
>>> [...]
>>> 1. Exception should be handled rarely, vs
>>> 2. Exception must be handled (either catch or throws).
>> [...]
>>       But coping with an error "rarely," if you just happened to be in a
>> merry mood the day you wrote the code, is a recipe for failure.  Errors
>> *will* occur, even if they occur only once per million executions, and
>> the code *must* do *something* in response.
>
> by "rarely" I mean if you have a call stack where method3 calls method2 which calls method1:
>
> method1()
> method2()
> method3()
>
> when method1 throws an exception and method3 knows how to handle it, method2 should not be forced to handle.  In real application the call stack can be very steep (many method calls) and for an exception only one frame/method knows how to handle the exception.  The other frames/methods should not be forced to handle it.  That's what I meant by "rarely".

     Peculiar usage, but okay.  If I may paraphrase: You would like a
deep-down method to inform a high-up method that something strange has
happened, while leaving all the in-between methods unaware that anything
out of the ordinary has occurred.

     Ugh.

     Furthermore (if I've understood you this time), you want the high-up
method to be unaware of the specific nature of the exceptions that may
be thrown from deep-down and percolate upward through the in-between.
When method3() calls method2(), it has no idea that method2() is going
to call method1() and hence no notion that a method1() call might fail,
nor in what manner.

     Ugh.

     My "Ugh's," of course, "prove" nothing.  But still ...

     Ugh.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33607

From	boxzou@gmail.com
Date	2016-02-04 15:51 -0800
Message-ID	<25eb1c05-80ea-4186-9272-3d2fd9fb1b9b@googlegroups.com>
In reply to	#33580

On Thursday, 4 February 2016 10:19:27 UTC-5, box...@gmail.com  wrote:
> http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
> 
> In the above link I proved in theory why checked exception is BAD.
> 
> It's sad to see that even though checked exceptions have been proven a mistake in practice and abandoned by major software packages like Spring Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a guideline on the official java tutorial:
> 
> https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
> ==================== begin quote ===============================================
> Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.
> ==================== end quote ===============================================
> 
> This is totally misinformation!  Checked exception is a mistake.  It should be rid of from Java (luckily no other language has this concept).

Thanks for every one reading my article and providing comments.

One thing I'd like to clarify is "Exception is brilliant, but Checked Exception is bad".

C does not have exception, it relies on return value and that's very easy to be ignored.  C++ introduces exception.  So that problem is solved.

Let's focus on the difference between checked and unchecked exception and on the contradiction caused by checked exception:

1. exception means handle later
2. checked exception means handle right now (through catch or throws).

So checked exception is itself a contradiction.  And this contradiction causes all kinds of problems.

[toc] | [prev] | [next] | [standalone]

#33608

From	boxzou@gmail.com
Date	2016-02-04 15:59 -0800
Message-ID	<16bcdbc8-2dd6-4f34-88d8-9d0fb5de4a18@googlegroups.com>
In reply to	#33607

On Thursday, 4 February 2016 18:51:55 UTC-5, box...@gmail.com  wrote:
> On Thursday, 4 February 2016 10:19:27 UTC-5, box...@gmail.com  wrote:
> > http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
> > 
> > In the above link I proved in theory why checked exception is BAD.
> > 
> > It's sad to see that even though checked exceptions have been proven a mistake in practice and abandoned by major software packages like Spring Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a guideline on the official java tutorial:
> > 
> > https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
> > ==================== begin quote ===============================================
> > Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.
> > ==================== end quote ===============================================
> > 
> > This is totally misinformation!  Checked exception is a mistake.  It should be rid of from Java (luckily no other language has this concept).
> 
> Thanks for every one reading my article and providing comments.
> 
> One thing I'd like to clarify is "Exception is brilliant, but Checked Exception is bad".
> 
> C does not have exception, it relies on return value and that's very easy to be ignored.  C++ introduces exception.  So that problem is solved.
> 
> Let's focus on the difference between checked and unchecked exception and on the contradiction caused by checked exception:
> 
> 1. exception means handle later
> 2. checked exception means handle right now (through catch or throws).
> 
> So checked exception is itself a contradiction.  And this contradiction causes all kinds of problems.

I should say:
1. exception means **usually/most of time** handle later

[toc] | [prev] | [next] | [standalone]

#33609

From	boxzou@gmail.com
Date	2016-02-04 16:03 -0800
Message-ID	<1af3c22c-4db2-4bd2-aa85-d468f1e43199@googlegroups.com>
In reply to	#33608

On Thursday, 4 February 2016 19:00:19 UTC-5, box...@gmail.com  wrote:
> On Thursday, 4 February 2016 18:51:55 UTC-5, box...@gmail.com  wrote:
> > On Thursday, 4 February 2016 10:19:27 UTC-5, box...@gmail.com  wrote:
> > > http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
> > > 
> > > In the above link I proved in theory why checked exception is BAD.
> > > 
> > > It's sad to see that even though checked exceptions have been proven a mistake in practice and abandoned by major software packages like Spring Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a guideline on the official java tutorial:
> > > 
> > > https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
> > > ==================== begin quote ===============================================
> > > Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.
> > > ==================== end quote ===============================================
> > > 
> > > This is totally misinformation!  Checked exception is a mistake.  It should be rid of from Java (luckily no other language has this concept).
> > 
> > Thanks for every one reading my article and providing comments.
> > 
> > One thing I'd like to clarify is "Exception is brilliant, but Checked Exception is bad".
> > 
> > C does not have exception, it relies on return value and that's very easy to be ignored.  C++ introduces exception.  So that problem is solved.
> > 
> > Let's focus on the difference between checked and unchecked exception and on the contradiction caused by checked exception:
> > 
> > 1. exception means handle later
> > 2. checked exception means handle right now (through catch or throws).
> > 
> > So checked exception is itself a contradiction.  And this contradiction causes all kinds of problems.
> 
> I should say:
> 1. exception means **usually/most of time** handle later
2. checked exception means **must always** handle right now (through catch or throws).

[toc] | [prev] | [next] | [standalone]

#33616

From	Eric Douglas <e.d.programmer@gmail.com>
Date	2016-02-05 05:33 -0800
Message-ID	<0fff586d-d220-425d-afd6-b5197c5b98da@googlegroups.com>
In reply to	#33607

On Thursday, February 4, 2016 at 6:51:55 PM UTC-5, box...@gmail.com wrote:
> Thanks for every one reading my article and providing comments.
> 
> One thing I'd like to clarify is "Exception is brilliant, but Checked Exception is bad".
> 
> C does not have exception, it relies on return value and that's very easy to be ignored.  C++ introduces exception.  So that problem is solved.
> 
> Let's focus on the difference between checked and unchecked exception and on the contradiction caused by checked exception:
> 
> 1. exception means handle later
> 2. checked exception means handle right now (through catch or throws).
> 
> So checked exception is itself a contradiction.  And this contradiction causes all kinds of problems.

If you don't like checked exceptions, use a different language.
Exceptions should occur rarely, should be handled frequently.

It may seem annoying to either declare that your method throws a new exception type or add a try method every time you add a call in your method to a method which could throw an exception, but I appreciate when methods tell me of possible issues.  The one problem I had was with a load method on the pdfbox API which threw an error (unchecked exception), and crashed my application because it's security class was inaccessible so it failed to load any secured PDF, even though 3 of the first 1,000 PDFs we got were secured.

[toc] | [prev] | [next] | [standalone]

#33611

From	Kevin McMurtrie <mcmurtrie@pixelmemory.us>
Date	2016-02-04 21:05 -0800
Message-ID	<mcmurtrie-FC8153.21055404022016@news.sonic.net>
In reply to	#33580

In article <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com>,
 boxzou@gmail.com wrote:

> http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
> 
> In the above link I proved in theory why checked exception is BAD.
> 
> It's sad to see that even though checked exceptions have been proven a 
> mistake in practice and abandoned by major software packages like Spring 
> Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a 
> guideline on the official java tutorial:
> 
> https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
> ==================== begin quote 
> ===============================================
> Here's the bottom line guideline: If a client can reasonably be expected to 
> recover from an exception, make it a checked exception. If a client cannot do 
> anything to recover from the exception, make it an unchecked exception.
> ==================== end quote 
> ===============================================
> 
> This is totally misinformation!  Checked exception is a mistake.  It should 
> be rid of from Java (luckily no other language has this concept).

Another fucking OCD programer on a crusade to abolish some feature that 
annoys him/her.

Please let the rest of us write proper code and make use of features 
exactly where they're needed.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →

csiph-web

Java Checked Exception is BAD!

Contents

#33776

#33777

#33778

#33779

#33781

#33782

#33783

#33785

#33787

#33788

#33791

#33792

#33793

#33689

#33619

#33607

#33608

#33609

#33616

#33611