Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #33580 > unrolled thread
| 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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-08 09:22 -0500 |
| Message-ID | <n9a859$l55$1@dont-email.me> |
| In reply to | #33648 |
On 2/7/2016 5:14 PM, boxzou@gmail.com wrote:
> On Saturday, 6 February 2016 09:44:12 UTC-5, Eric Sosman wrote:
>> [...]
>> There are, of course, places where the entire exception mechanism --
>> checked or not -- becomes awkward. Somebody's already mentioned how
>> poorly stream operations interact with exceptions; [...]
>> --
>> esosman@comcast-dot-net.invalid
>> "Don't be afraid of work. Make work afraid of you." -- TLM
Aside: It's considered poor form to quote Usenet signatures.
> good you see problem with checked exception with pipelines. [...]
The unfortunate interaction between exceptions and pipelines remains
whether the exceptions are checked or unchecked. The difficulty lies in
their asynchronicity, not in their checkedness.
When an exception is thrown from some stage in a pipeline, Java
tries to stop the whole pipeline and deliver the exception to the
invoker. But in a parallel pipeline Java can't guarantee that all the
branches will stop at the exact same moment, and further exceptions may
be thrown from still-executing branches. But there's only one catch
clause for all of them (in the invoker or in one of its ancestors), and
that catch clause can handle only one exception per `try'! So, what
happens to the others? They just vanish.
Below is a little class I wrote to illustrate the problem. Its
exact behavior depends on what random numbers appear and what the
timing of different events is like, but on my machine one run produced
(lots of lines of normal output)
java.lang.RuntimeException: java.lang.RuntimeException: 90
Threw 4 exceptions, caught 1
On this run, three exceptions -- three UNchecked exceptions -- simply
disappeared into the ether. Throwables of ANY kind play poorly with
parallel pipelines; you cannot blame the problem on checked exceptions.
The code:
import java.util.concurrent.ThreadLocalRandom;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.stream.IntStream;
public class Foo {
private static final AtomicInteger THROWN = new AtomicInteger(0);
private static final AtomicInteger CAUGHT = new AtomicInteger(0);
public static void main(String[] unused) {
IntStream stream = IntStream.range(1, 100).parallel();
System.out.println(stream);
System.out.println(stream.isParallel() ? "parallel" : "sequential");
try {
stream.mapToObj((i) -> new Foo(i)).forEach((f) -> f.doit());
} catch (Throwable ex) {
CAUGHT.incrementAndGet();
System.err.println(ex);
}
System.err.printf("Threw %s exceptions, caught %s%n", THROWN,
CAUGHT);
}
private final int value;
private Foo(int value) {
this.value = value;
}
private void doit() {
int delay = ThreadLocalRandom.current().nextInt(100, 1000);
try {
Thread.sleep(delay);
} catch (InterruptedException ex) {
// Don't care.
}
System.err.println(value + " " + Thread.currentThread());
if (ThreadLocalRandom.current().nextInt(10) == 0) {
THROWN.incrementAndGet();
throw new RuntimeException(Integer.toString(value));
}
}
}
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 11:01 -0800 |
| Message-ID | <ab875f99-bcd5-4bd2-a450-38149f3635a3@googlegroups.com> |
| In reply to | #33678 |
On Monday, 8 February 2016 09:22:28 UTC-5, Eric Sosman wrote:
> On 2/7/2016 5:14 PM, b...@gmail.com wrote:
> > On Saturday, 6 February 2016 09:44:12 UTC-5, Eric Sosman wrote:
> >> [...]
> >> There are, of course, places where the entire exception mechanism --
> >> checked or not -- becomes awkward. Somebody's already mentioned how
> >> poorly stream operations interact with exceptions; [...]
> >> --
> >> esosman@comcast-dot-net.invalid
> >> "Don't be afraid of work. Make work afraid of you." -- TLM
>
> Aside: It's considered poor form to quote Usenet signatures.
>
> > good you see problem with checked exception with pipelines. [...]
>
> The unfortunate interaction between exceptions and pipelines remains
> whether the exceptions are checked or unchecked. The difficulty lies in
> their asynchronicity, not in their checkedness.
>
> When an exception is thrown from some stage in a pipeline, Java
> tries to stop the whole pipeline and deliver the exception to the
> invoker. But in a parallel pipeline Java can't guarantee that all the
> branches will stop at the exact same moment, and further exceptions may
> be thrown from still-executing branches. But there's only one catch
> clause for all of them (in the invoker or in one of its ancestors), and
> that catch clause can handle only one exception per `try'! So, what
> happens to the others? They just vanish.
>
> Below is a little class I wrote to illustrate the problem. Its
> exact behavior depends on what random numbers appear and what the
> timing of different events is like, but on my machine one run produced
>
> (lots of lines of normal output)
> java.lang.RuntimeException: java.lang.RuntimeException: 90
> Threw 4 exceptions, caught 1
>
> On this run, three exceptions -- three UNchecked exceptions -- simply
> disappeared into the ether. Throwables of ANY kind play poorly with
> parallel pipelines; you cannot blame the problem on checked exceptions.
>
> The code:
>
> import java.util.concurrent.ThreadLocalRandom;
> import java.util.concurrent.atomic.AtomicInteger;
> import java.util.stream.IntStream;
>
> public class Foo {
>
> private static final AtomicInteger THROWN = new AtomicInteger(0);
> private static final AtomicInteger CAUGHT = new AtomicInteger(0);
>
> public static void main(String[] unused) {
> IntStream stream = IntStream.range(1, 100).parallel();
> System.out.println(stream);
> System.out.println(stream.isParallel() ? "parallel" : "sequential");
> try {
> stream.mapToObj((i) -> new Foo(i)).forEach((f) -> f.doit());
> } catch (Throwable ex) {
> CAUGHT.incrementAndGet();
> System.err.println(ex);
> }
>
> System.err.printf("Threw %s exceptions, caught %s%n", THROWN,
> CAUGHT);
> }
>
> private final int value;
>
> private Foo(int value) {
> this.value = value;
> }
>
> private void doit() {
> int delay = ThreadLocalRandom.current().nextInt(100, 1000);
> try {
> Thread.sleep(delay);
> } catch (InterruptedException ex) {
> // Don't care.
> }
> System.err.println(value + " " + Thread.currentThread());
> if (ThreadLocalRandom.current().nextInt(10) == 0) {
> THROWN.incrementAndGet();
> throw new RuntimeException(Integer.toString(value));
> }
> }
> }
>
> --
> esosman@comcast-dot-net.invalid
> "Don't be afraid of work. Make work afraid of you." -- TLM
That's very complicated. Up to now I tried hard to have my code run on the same thread. A few places do have to divide the work but that division happens at a very high level and uses only an ID. The pipeline has too much magic. I haven't tried that yet. But as you said that has nothing to do with checked/unchecked exception. But in a serialized pipeline case, checked exception is hard to handle because of the interfaces used.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 11:08 -0800 |
| Message-ID | <161d7bfa-9fb7-4c0d-a8b3-dbab59954f3c@googlegroups.com> |
| In reply to | #33678 |
> Aside: It's considered poor form to quote Usenet signatures. Sorry, I didn't understand what you meant. But now I do. I'll remove them in future replies.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-08 22:02 +0100 |
| Message-ID | <n9avq4$j49$1@news.albasani.net> |
| In reply to | #33678 |
Am 08.02.2016 15:22, schrieb Eric Sosman: [snip] > > The unfortunate interaction between exceptions and pipelines remains > whether the exceptions are checked or unchecked. The difficulty lies in > their asynchronicity, not in their checkedness. [snip] The example involving forEach that I posted in this thread was problematic exactly because forEach takes a Consumer, which can't throw a checked exception. All the most important functional interfaces in Java can't, and it makes many libraries a pain to use. Another case: just look at the hoops that CompletableFuture has to jump through with wrapping and unwrapping CompletionExceptions, which is a wrapper that is only needed to tunnel checked exceptions through the APIs. Terrible stuff. The language definitely stands on its own toes there. The problem of vanishing parallel exceptions is orthogonal to that, and indeed independent of whether they are checked or not. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:09 -0800 |
| Message-ID | <6e3778e5-95d3-459e-9453-7ff7ebf38728@googlegroups.com> |
| In reply to | #33624 |
On Saturday, 6 February 2016 09:16:44 UTC-5, Martin Gregorie wrote: > On Sat, 06 Feb 2016 08:38:23 -0500, Eric Sosman wrote: > > > Read the Javadoc? Well, no: You've already told us that listing > > nine things in the throws clause is too much clutter to be considered > > acceptable, so writing nine entire @throws paragraphs in the Javadoc > > would be even more clutter, even less acceptable. So, again: How many > > of these nine exceptions should be Deep Dark Secrets from anyone who > > might want to call method3()? > > > I have a tendency to write classes that trap the checked exceptions > thrown by classes they call, deal with the non-fatal exceptions and use > the remainder, along with any events my code generated and can't handle, > to generate instances of the one or two exception types (one for fatals, > the other for non-fatals, that my class's methods can throw. Those thrown > as the result of lower lever fatals will contain the message etc from the > inner exception, so they're effectively wrappers for them. > > This works for me and has the benefit of leaving only one or two > exception types for outer classes to deal with, but is it generally > considered to be a good or a bad approach? > > > -- > martin@ | Martin Gregorie > gregorie. | Essex, UK > org | you did that exactly because we have checked exception.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-07 23:29 +0000 |
| Message-ID | <n98jvs$rpt$2@dont-email.me> |
| In reply to | #33646 |
On Sun, 07 Feb 2016 14:09:44 -0800, boxzou wrote: > On Saturday, 6 February 2016 09:16:44 UTC-5, Martin Gregorie wrote: >> On Sat, 06 Feb 2016 08:38:23 -0500, Eric Sosman wrote: >> >> > Read the Javadoc? Well, no: You've already told us that listing >> > nine things in the throws clause is too much clutter to be considered >> > acceptable, so writing nine entire @throws paragraphs in the Javadoc >> > would be even more clutter, even less acceptable. So, again: How >> > many of these nine exceptions should be Deep Dark Secrets from anyone >> > who might want to call method3()? >> > >> I have a tendency to write classes that trap the checked exceptions >> thrown by classes they call, deal with the non-fatal exceptions and use >> the remainder, along with any events my code generated and can't >> handle, to generate instances of the one or two exception types (one >> for fatals, the other for non-fatals, that my class's methods can >> throw. Those thrown as the result of lower lever fatals will contain >> the message etc from the inner exception, so they're effectively >> wrappers for them. >> >> This works for me and has the benefit of leaving only one or two >> exception types for outer classes to deal with, but is it generally >> considered to be a good or a bad approach? >> >> >> -- >> martin@ | Martin Gregorie gregorie. | Essex, UK org | > > you did that exactly because we have checked exception. ... which I want javadocs to document for the benefit of anybody else (or myself in 6 - 12 months time) who needs to use the class. FYI I maintain a jarfile containing classes I've written that I'll likely reuse in future. Some, such as an enhanced version of the C getopt() function, will get used for every Java program I write, while others are more specialised so of course I expect javadocs for that jarfile to tell me which methods throw what exceptions. Anything which prevents javadocs providing complete documentation of any classes I write gets the BIG DOWNVOTE from me: I do not want to read code to find out what the javadocs produced documentation should have told me. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-08 21:49 +0100 |
| Message-ID | <n9av1f$hed$1@news.albasani.net> |
| In reply to | #33654 |
Am 08.02.2016 00:29, schrieb Martin Gregorie: > ... which I want javadocs to document for the benefit of anybody else (or > myself in 6 - 12 months time) who needs to use the class. > [snip] > > Anything which prevents javadocs providing complete documentation of any > classes I write gets the BIG DOWNVOTE from me: I do not want to read code > to find out what the javadocs produced documentation should have told me. > Quite so, I agree completely, but this is beside the point under discussion. Nothing should keep you from documenting what exceptions a method might throw, even if they are unchecked exceptions. For example, I quite often document (in javadocs) under what circumstances exactly some method would throw IllegalArgumentException. You van even put in an explicit throws-clause if you're only having generated javadocs. No problem here, as far as I can see. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-08 17:23 -0500 |
| Message-ID | <n9b4bn$be8$1@dont-email.me> |
| In reply to | #33687 |
On 2/8/2016 3:49 PM, Sebastian wrote:
> Am 08.02.2016 00:29, schrieb Martin Gregorie:
>
>> ... which I want javadocs to document for the benefit of anybody else (or
>> myself in 6 - 12 months time) who needs to use the class.
>>
> [snip]
>>
>> Anything which prevents javadocs providing complete documentation of any
>> classes I write gets the BIG DOWNVOTE from me: I do not want to read code
>> to find out what the javadocs produced documentation should have told me.
>>
> Quite so, I agree completely, but this is beside the point under
> discussion. Nothing should keep you from documenting what exceptions a
> method might throw, even if they are unchecked exceptions. For example,
> I quite often document (in javadocs) under what circumstances exactly
> some method would throw IllegalArgumentException. You van even put in an
> explicit throws-clause if you're only having generated javadocs. No
> problem here, as far as I can see.
The O.P. objected to the "clutter" of listing multiple exception
classes in a `throws' clause. The "clutter" of listing them all in
`@throws' paragraphs -- along with the explanations of what provokes
them -- is vastly greater, so I asked him whether he thought omitting
the `@throws' documentation would be an improvement.
And he wrote
"[...] javadoc can't list all the exceptions either [...]"
which gets the same BIG DOWNVOTE from me, too. A programmer who won't
document his code is doing no one any favors.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 18:46 -0800 |
| Message-ID | <37622de9-e99f-4a19-a8e0-8e9199fb91ea@googlegroups.com> |
| In reply to | #33694 |
On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: > On 2/8/2016 3:49 PM, Sebastian wrote: > > Am 08.02.2016 00:29, schrieb Martin Gregorie: > > > >> ... which I want javadocs to document for the benefit of anybody else (or > >> myself in 6 - 12 months time) who needs to use the class. > >> > > [snip] > >> > >> Anything which prevents javadocs providing complete documentation of any > >> classes I write gets the BIG DOWNVOTE from me: I do not want to read code > >> to find out what the javadocs produced documentation should have told me. > >> > > Quite so, I agree completely, but this is beside the point under > > discussion. Nothing should keep you from documenting what exceptions a > > method might throw, even if they are unchecked exceptions. For example, > > I quite often document (in javadocs) under what circumstances exactly > > some method would throw IllegalArgumentException. You van even put in an > > explicit throws-clause if you're only having generated javadocs. No > > problem here, as far as I can see. > > The O.P. objected to the "clutter" of listing multiple exception > classes in a `throws' clause. The "clutter" of listing them all in > `@throws' paragraphs -- along with the explanations of what provokes > them -- is vastly greater, so I asked him whether he thought omitting > the `@throws' documentation would be an improvement. > > And he wrote > > "[...] javadoc can't list all the exceptions either [...]" > > which gets the same BIG DOWNVOTE from me, too. A programmer who won't > document his code is doing no one any favors. > that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands?
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-09 08:21 +0100 |
| Message-ID | <n9c42m$npk$1@news.albasani.net> |
| In reply to | #33703 |
Am 09.02.2016 03:46, schrieb boxzou@gmail.com: > On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: >> >> And he wrote >> >> "[...] javadoc can't list all the exceptions either [...]" >> >> which gets the same BIG DOWNVOTE from me, too. A programmer who won't >> document his code is doing no one any favors. >> > that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. > > Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? > Isn't that where wrapping for once is useful? Like InvocationTargetException? -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-09 04:58 -0800 |
| Message-ID | <575f130e-2444-4eb8-bf11-91f13e1fb44b@googlegroups.com> |
| In reply to | #33709 |
On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: > Am 09.02.2016 03:46, schrieb b...@gmail.com: > > On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: > >> > >> And he wrote > >> > >> "[...] javadoc can't list all the exceptions either [...]" > >> > >> which gets the same BIG DOWNVOTE from me, too. A programmer who won't > >> document his code is doing no one any favors. > >> > > that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. > > > > Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? > > > Isn't that where wrapping for once is useful? Like > InvocationTargetException? wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-09 08:17 -0500 |
| Message-ID | <n9coos$9ht$1@dont-email.me> |
| In reply to | #33713 |
On 2/9/2016 7:58 AM, boxzou@gmail.com wrote:
> On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote:
>> Am 09.02.2016 03:46, schrieb b...@gmail.com:
>>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote:
>>>>
>>>> And he wrote
>>>>
>>>> "[...] javadoc can't list all the exceptions either [...]"
>>>>
>>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't
>>>> document his code is doing no one any favors.
>>>>
>>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it.
>>>
>>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands?
>>>
>> Isn't that where wrapping for once is useful? Like
>> InvocationTargetException?
>
> wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it?
Logging is not handling.
Logging is a useful adjunct to handling, in that it exposes some
information for post-event analysis: debugging, health monitoring, and
all the rest.
Your boss says "Perform this task," but you're unable. Logging is
writing "I can't" on a sticky note your boss doesn't see. He will be
unhappy if that's all you do, because you didn't "handle" his task:
You "dropped" it.
Question: What does the catch block do beyond emitting a log entry?
Throw a new exception? Re-throw the original? Close a few streams?
Mark a cache entry as "stale?" Abandon the current operation and move
on to the next? Some combination of these and other actions?
*That's* handling.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-09 07:57 -0800 |
| Message-ID | <fda62272-314a-4f2d-bd67-42f4f17c31ba@googlegroups.com> |
| In reply to | #33715 |
On Tuesday, 9 February 2016 08:18:14 UTC-5, Eric Sosman wrote: > On 2/9/2016 7:58 AM, b...@gmail.com wrote: > > On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: > >> Am 09.02.2016 03:46, schrieb b...@gmail.com: > >>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: > >>>> > >>>> And he wrote > >>>> > >>>> "[...] javadoc can't list all the exceptions either [...]" > >>>> > >>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't > >>>> document his code is doing no one any favors. > >>>> > >>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. > >>> > >>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? > >>> > >> Isn't that where wrapping for once is useful? Like > >> InvocationTargetException? > > > > wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? > > Logging is not handling. > > Logging is a useful adjunct to handling, in that it exposes some > information for post-event analysis: debugging, health monitoring, and > all the rest. > > Your boss says "Perform this task," but you're unable. Logging is > writing "I can't" on a sticky note your boss doesn't see. He will be > unhappy if that's all you do, because you didn't "handle" his task: > You "dropped" it. > > Question: What does the catch block do beyond emitting a log entry? > Throw a new exception? Re-throw the original? Close a few streams? > Mark a cache entry as "stale?" Abandon the current operation and move > on to the next? Some combination of these and other actions? > > *That's* handling. > Your handling is not handling at all. Those are cleanup, which should be done in a finally block.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-10 02:37 +0100 |
| Message-ID | <n9e499$4m0$1@news.albasani.net> |
| In reply to | #33725 |
Am 09.02.2016 16:57, schrieb boxzou@gmail.com: > On Tuesday, 9 February 2016 08:18:14 UTC-5, Eric Sosman wrote: >> On 2/9/2016 7:58 AM, b...@gmail.com wrote: >>> On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: >>>> Am 09.02.2016 03:46, schrieb b...@gmail.com: >>>>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: >>>>>> >>>>>> And he wrote >>>>>> >>>>>> "[...] javadoc can't list all the exceptions either [...]" >>>>>> >>>>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't >>>>>> document his code is doing no one any favors. >>>>>> >>>>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. >>>>> >>>>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? >>>>> >>>> Isn't that where wrapping for once is useful? Like >>>> InvocationTargetException? >>> >>> wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? >> >> Logging is not handling. >> >> Logging is a useful adjunct to handling, in that it exposes some >> information for post-event analysis: debugging, health monitoring, and >> all the rest. >> >> Your boss says "Perform this task," but you're unable. Logging is >> writing "I can't" on a sticky note your boss doesn't see. He will be >> unhappy if that's all you do, because you didn't "handle" his task: >> You "dropped" it. >> >> Question: What does the catch block do beyond emitting a log entry? >> Throw a new exception? Re-throw the original? Close a few streams? >> Mark a cache entry as "stale?" Abandon the current operation and move >> on to the next? Some combination of these and other actions? >> >> *That's* handling. >> > Your handling is not handling at all. Those are cleanup, which should be done in a finally block. > Closing streams would typically happen in a finally block. But all the rest of Eric's examples seem to me perfectly reasonable things one might do in a catch block. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-10 18:58 -0800 |
| Message-ID | <8bfc5048-297e-459e-8c3f-3752fb4046b5@googlegroups.com> |
| In reply to | #33740 |
On Tuesday, 9 February 2016 20:37:52 UTC-5, Sebastian wrote: > Am 09.02.2016 16:57, schrieb b...@gmail.com: > > On Tuesday, 9 February 2016 08:18:14 UTC-5, Eric Sosman wrote: > >> On 2/9/2016 7:58 AM, b...@gmail.com wrote: > >>> On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: > >>>> Am 09.02.2016 03:46, schrieb b...@gmail.com: > >>>>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: > >>>>>> > >>>>>> And he wrote > >>>>>> > >>>>>> "[...] javadoc can't list all the exceptions either [...]" > >>>>>> > >>>>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't > >>>>>> document his code is doing no one any favors. > >>>>>> > >>>>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. > >>>>> > >>>>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? > >>>>> > >>>> Isn't that where wrapping for once is useful? Like > >>>> InvocationTargetException? > >>> > >>> wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? > >> > >> Logging is not handling. > >> > >> Logging is a useful adjunct to handling, in that it exposes some > >> information for post-event analysis: debugging, health monitoring, and > >> all the rest. > >> > >> Your boss says "Perform this task," but you're unable. Logging is > >> writing "I can't" on a sticky note your boss doesn't see. He will be > >> unhappy if that's all you do, because you didn't "handle" his task: > >> You "dropped" it. > >> > >> Question: What does the catch block do beyond emitting a log entry? > >> Throw a new exception? Re-throw the original? Close a few streams? > >> Mark a cache entry as "stale?" Abandon the current operation and move > >> on to the next? Some combination of these and other actions? > >> > >> *That's* handling. > >> > > Your handling is not handling at all. Those are cleanup, which should be done in a finally block. > > > Closing streams would typically happen in a finally block. But all the > rest of Eric's examples seem to me perfectly reasonable things one might > do in a catch block. Correct, but he basically explained what catch can do. I never said do not use catch. But catch should be used to do meaningful exception handling. Wrapping, logging at the mid call stack level, swallowing are not meaningful handling. If there is no checked exception, wrapping, logging at mid call stack, swallowing won't happen. We don't even need InvocationTargetException! I surveyed our code and found >50% catches were dedicated to wrapping excpetions and 18% were for useless and redundant logging. meaningful catches were only 20%. That's on the basis that I already significantly used lots of unchecked exceptions. I guess in projects using checked exceptions probably 80~90% of catches would be dedicated to exception wrapping. So go back to your projects and do some statistics and post your result here. Please do include your project size like how many java files and total number of lines of code.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-11 08:13 -0500 |
| Message-ID | <n9i199$7mp$1@dont-email.me> |
| In reply to | #33763 |
On 2/10/2016 9:58 PM, boxzou@gmail.com wrote:
> On Tuesday, 9 February 2016 20:37:52 UTC-5, Sebastian wrote:
>> Am 09.02.2016 16:57, schrieb b...@gmail.com:
>>> On Tuesday, 9 February 2016 08:18:14 UTC-5, Eric Sosman wrote:
>>>> On 2/9/2016 7:58 AM, b...@gmail.com wrote:
>>>>> On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote:
>>>>>> Am 09.02.2016 03:46, schrieb b...@gmail.com:
>>>>>>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote:
>>>>>>>>
>>>>>>>> And he wrote
>>>>>>>>
>>>>>>>> "[...] javadoc can't list all the exceptions either [...]"
>>>>>>>>
>>>>>>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't
>>>>>>>> document his code is doing no one any favors.
>>>>>>>>
>>>>>>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it.
>>>>>>>
>>>>>>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands?
>>>>>>>
>>>>>> Isn't that where wrapping for once is useful? Like
>>>>>> InvocationTargetException?
>>>>>
>>>>> wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it?
>>>>
>>>> Logging is not handling.
>>>>
>>>> Logging is a useful adjunct to handling, in that it exposes some
>>>> information for post-event analysis: debugging, health monitoring, and
>>>> all the rest.
>>>>
>>>> Your boss says "Perform this task," but you're unable. Logging is
>>>> writing "I can't" on a sticky note your boss doesn't see. He will be
>>>> unhappy if that's all you do, because you didn't "handle" his task:
>>>> You "dropped" it.
>>>>
>>>> Question: What does the catch block do beyond emitting a log entry?
>>>> Throw a new exception? Re-throw the original? Close a few streams?
>>>> Mark a cache entry as "stale?" Abandon the current operation and move
>>>> on to the next? Some combination of these and other actions?
>>>>
>>>> *That's* handling.
>>>>
>>> Your handling is not handling at all. Those are cleanup, which should be done in a finally block.
>>>
>> Closing streams would typically happen in a finally block. But all the
>> rest of Eric's examples seem to me perfectly reasonable things one might
>> do in a catch block.
>
> Correct, but he basically explained what catch can do. I never said do not use catch. But catch should be used to do meaningful exception handling. Wrapping, logging at the mid call stack level, swallowing are not meaningful handling. If there is no checked exception, wrapping, logging at mid call stack, swallowing won't happen. We don't even need InvocationTargetException!
You haven't said "do not use catch." But you *have* said that
exceptions should not be documented, neither in a `throws' clause nor
in a Javadoc `@throws' paragraph! So, what exceptions should I catch,
and how should I interpret what they mean?
Here's a method in the style you have advocated:
/**
* Establishes the tone of this debate.
* @param tone The tone of this debate.
*/
public void boxzou(Tone tone) {
// ...
}
Should I enclose a call to this method in a `try' block? Why, or
why not? What exceptions might it throw, and why? Which of those
exceptions are irredeemable, and which might indicate temporary
conditions that might clear up if retried?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-02-11 14:02 -0800 |
| Message-ID | <d84a1785-a7ae-46e9-aec2-591676ee61e1@googlegroups.com> |
| In reply to | #33763 |
On Wednesday, February 10, 2016 at 6:58:42 PM UTC-8, box...@gmail.com wrote: > I surveyed our code and found >50% catches were dedicated to wrapping excpetions and 18% were for useless and redundant logging. meaningful catches were only 20%. That's on the basis that I already significantly used lots of unchecked exceptions. I guess in projects using checked exceptions probably 80~90% of catches would be dedicated to exception wrapping. So go back to your projects and do some statistics and post your result here. Please do include your project size like how many java files and total number of lines of code. That's a lot of bad coding. You blame exceptions for that? -- Lew
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-11 16:41 -0800 |
| Message-ID | <f8708b7b-53c1-4bce-970b-4993d7be6cb9@googlegroups.com> |
| In reply to | #33780 |
On Thursday, 11 February 2016 17:03:00 UTC-5, Lew wrote: > On Wednesday, February 10, 2016 at 6:58:42 PM UTC-8, box...@gmail.com wrote: > > I surveyed our code and found >50% catches were dedicated to wrapping excpetions and 18% were for useless and redundant logging. meaningful catches were only 20%. That's on the basis that I already significantly used lots of unchecked exceptions. I guess in projects using checked exceptions probably 80~90% of catches would be dedicated to exception wrapping. So go back to your projects and do some statistics and post your result here. Please do include your project size like how many java files and total number of lines of code. > > That's a lot of bad coding. You blame exceptions for that? > that's exactly caused by CHECKED exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-10 02:31 +0100 |
| Message-ID | <n9e3tg$49d$1@news.albasani.net> |
| In reply to | #33713 |
Am 09.02.2016 13:58, schrieb boxzou@gmail.com: > On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: >> Am 09.02.2016 03:46, schrieb b...@gmail.com: >>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: >>>> >>>> And he wrote >>>> >>>> "[...] javadoc can't list all the exceptions either [...]" >>>> >>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't >>>> document his code is doing no one any favors. >>>> >>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. >>> >>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? >>> >> Isn't that where wrapping for once is useful? Like >> InvocationTargetException? > > wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? > > Well, yes. InvocationTargetException is useful because it tells you it's not your component at fault, but the called code, whatever it does, to which you might react by trying again, or calling some other component, or returning a default result, whatever. -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-10 18:47 -0800 |
| Message-ID | <2a31042a-e149-4606-840a-9fabd82eb0d9@googlegroups.com> |
| In reply to | #33738 |
On Tuesday, 9 February 2016 20:31:37 UTC-5, Sebastian wrote: > Am 09.02.2016 13:58, schrieb b...@gmail.com: > > On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: > >> Am 09.02.2016 03:46, schrieb b...@gmail.com: > >>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: > >>>> > >>>> And he wrote > >>>> > >>>> "[...] javadoc can't list all the exceptions either [...]" > >>>> > >>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't > >>>> document his code is doing no one any favors. > >>>> > >>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. > >>> > >>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? > >>> > >> Isn't that where wrapping for once is useful? Like > >> InvocationTargetException? > > > > wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? > > > > > Well, yes. InvocationTargetException is useful because it tells you it's > not your component at fault, but the called code, whatever it does, to > which you might react by trying again, or calling some other component, > or returning a default result, whatever. > How do you know it's not your code? If you use pipelines, you will get InvocationTargetExeptions with your exception as cause. Now you have to get the cause and figure out. If there is no checked exception, this is totally unnecessary.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web