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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-09 12:26 +0000 |
| Message-ID | <n9cltr$qgl$2@dont-email.me> |
| In reply to | #33703 |
On Mon, 08 Feb 2016 18:46:57 -0800, boxzou wrote: > 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? > Now you're being silly. SSH isn't written in Java. In cases like this you'd check the function's result code, if non-zero, compare it with the constants in errno.h to see if this is something you want to deal with and treat the rest as fatals by calling strerror() to get the corresponding error text, display it and exit from the program using the result code as the exit status so the calling process knows about the failure. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-09 04:57 -0800 |
| Message-ID | <9cb93501-b58e-4635-935f-075c13f6d9ce@googlegroups.com> |
| In reply to | #33711 |
On Tuesday, 9 February 2016 07:29:40 UTC-5, Martin Gregorie wrote: > On Mon, 08 Feb 2016 18:46:57 -0800, boxzou wrote: > > > 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? > > > Now you're being silly. SSH isn't written in Java. > > In cases like this you'd check the function's result code, if non-zero, > compare it with the constants in errno.h to see if this is something you > want to deal with and treat the rest as fatals by calling strerror() to > get the corresponding error text, display it and exit from the program > using the result code as the exit status so the calling process knows > about the failure. > > > -- > martin@ | Martin Gregorie > gregorie. | Essex, UK > org | there are SSH client in java and also ssh server in java. client example: trilead. server example: http://mina.apache.org/sshd-project/
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-09 18:27 +0000 |
| Message-ID | <n9db20$gap$1@dont-email.me> |
| In reply to | #33712 |
On Tue, 09 Feb 2016 04:57:20 -0800, boxzou wrote: > On Tuesday, 9 February 2016 07:29:40 UTC-5, Martin Gregorie wrote: >> On Mon, 08 Feb 2016 18:46:57 -0800, boxzou wrote: >> >> > 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? >> > >> Now you're being silly. SSH isn't written in Java. >> >> In cases like this you'd check the function's result code, if non-zero, >> compare it with the constants in errno.h to see if this is something >> you want to deal with and treat the rest as fatals by calling >> strerror() to get the corresponding error text, display it and exit >> from the program using the result code as the exit status so the >> calling process knows about the failure. >> >> >> -- >> martin@ | Martin Gregorie gregorie. | Essex, UK org | > > there are SSH client in java and also ssh server in java. client > example: trilead. server example: http://mina.apache.org/sshd-project/ So, somebody has written ssh comonents in Java. Good for them. However, that's rather a special case, isn't it. Mention SSH, and 90% plus of those who have heard of will assume you mean their operating system's port of OpenSSH which, as I said, is written in C. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 20:19 -0800 |
| Message-ID | <4d1a7c06-7e46-4dc2-9b53-ec1183da1fad@googlegroups.com> |
| In reply to | #33623 |
On Saturday, 6 February 2016 08:38:54 UTC-5, Eric Sosman wrote: > On 2/5/2016 7:09 PM, b...@gmail.com wrote: > >[...] > > As you said, if a runtime exception is thrown from method1 and method2 does not know how to handle it, method2 does not need to do anything and method3 can still catch that exception and handle it. The developer need know method2 might throw this exception. I am afraid we can not rely on checked exception to document this exception. Why? Suppose we have > > > > method3 calls method2a and method2b and method2c > > method2a calls method1a1 and method1a2 and method1a3 > > method2b calls method1b1 and mehtod1b2 and method1b3 > > method2c calls method1c1 and mehtod1c2 and method1c3 > > and each method1xy throws one exception say Exception1xy > > now method3 signature would be > > method3(...)throws Exception1a1, Exception1ab, Exception1a3, Exception1b1, Exception1b2, Exception1b3, Exception1c1, Exception1c2, Exception1c3 > > > > Do you think this will scale? [...] > > Question: Which of these nine exceptions should *not* be described > in the Javadoc? > > Imagine yourself writing method4(), and writing a call to method3() > within it. "Hmmm," you say to yourself, "Can anything go wrong with the > method3() call? Is there anything I ought to be aware of, and perhaps > try to cope with if it should happen?" What should you do to try to > answer your question? > > 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()? > > -- > esosman@comcast-dot-net.invalid > "Don't be afraid of work. Make work afraid of you." -- TLM You're right, javadoc can't list all the exceptions either because the number of exceptions grows exponentially. You may list just the ones that are possible to be handled, e.g for JPA EntityManager.persist(obj), only list ObjectAlreadyInDBException. Or you don't list anything at all, I think that's the approach JPA adopted. Since Javadoc is optional, you don't have to list all exceptions. How to find the exceptions then? I actually think about the exceptions that my method can handle and devise tests to have the exceptions thrown and then catch those exceptions. I let all other exceptions fly till application server thread catches it or if the thread is started by my code, I have a catch(Throwable ex) and log the exception.
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2016-02-06 16:01 +0100 |
| Message-ID | <dhmg70F2luoU1@mid.individual.net> |
| In reply to | #33621 |
On 06.02.2016 01:09, boxzou@gmail.com wrote: > On Friday, 5 February 2016 11:47:16 UTC-5, Eric Douglas wrote: >> On Friday, February 5, 2016 at 11:26:04 AM UTC-5, box...@gmail.com wrote: >>> 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". >>> >>> In application server case, usually most exceptions are just logged by the application server so that the application (and server) does not crash on an exception. There are very limited an app can do on most exceptions, like network outage, file accidentally removed, data accidentally removed from db, or due to bugs, these would usually require human intervention (fix network outage, put file back, fix data, fix bug etc). >> >> You still don't get it, and you still have yet to show a good example of how what you perceive to be a problem should be solved. >> How can any method "not be forced to handle" any exception? If method3 calls method2 which calls method1 and method1 encounters an exception do you think the norm should be to log the exception and continue as if nothing is wrong, or how do you propose method1 should tell method3 about the problem without telling method2? It could throw an unchecked exception, which method2 wouldn't have to do anything for and method3 could still catch, but the programmer writing method3 still needs to know about the possibility of this exception and code for it. It sounds like you're just making the huge assumption that causes many of the program errors in any language, that every programmer just knows every possible runtime error and writes handlers for them. > > As you said, if a runtime exception is thrown from method1 and method2 does not know how to handle it, method2 does not need to do anything and method3 can still catch that exception and handle it. The developer need know method2 might throw this exception. I am afraid we can not rely on checked exception to document this exception. Why? Suppose we have > > method3 calls method2a and method2b and method2c > method2a calls method1a1 and method1a2 and method1a3 > method2b calls method1b1 and mehtod1b2 and method1b3 > method2c calls method1c1 and mehtod1c2 and method1c3 > and each method1xy throws one exception say Exception1xy > now method3 signature would be > method3(...)throws Exception1a1, Exception1ab, Exception1a3, Exception1b1, Exception1b2, Exception1b3, Exception1c1, Exception1c2, Exception1c3 > > Do you think this will scale? That's why JDBC has SQLException and SpringFramework/JPA/Guice abandons checked exception altogether. I don't know why they did it. Can you provide any references to the reasoning of those projects to abandon checked exceptions? > This is only 3 levels, enterprise applications sometimes have 20+ levels. the throws clause would grow exponentially for each method. Soon the code would be nothing but exceptions! This is silly - for a number of reasons: - all intermediate methods can choose what exception to catch themselves and what they throw. - they can especially choose to throw another exception type wrapping the original one. - inheritance also works for exceptions Hiding exception conditions does not make all the ways go away in which various functionalities can fail. You need flexible and robust ways to handle them. That's what you get with exceptions. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | 4ndre4 <4ndre4@4ndre4.com.invalid> |
|---|---|
| Date | 2016-02-06 15:10 +0000 |
| Message-ID | <n9527l$ptu$2@dont-email.me> |
| In reply to | #33628 |
On 06/02/2016 15:01, Robert Klemme wrote: [...] >> Do you think this will scale? That's why JDBC has SQLException and >> SpringFramework/JPA/Guice abandons checked exception altogether. > > I don't know why they did it. Can you provide any references to the > reasoning of those projects to abandon checked exceptions? "Newer Java APIs such as the Spring Framework and the Java Data Objects library have little or no reliance on checked exceptions. The Hibernate ORM framework redefined key facilities as of release 3.0 to eliminate the use of checked exceptions. This reflects the realization that the great majority of the exception conditions that these frameworks report are unrecoverable, stemming from incorrect coding of a method call, or a failure of some underlying component such as a database server. Practically speaking, there is almost no benefit to be gained by forcing a caller to catch or declare such exceptions." - http://www.oracle.com/technetwork/articles/entarch/effective-exceptions2-097044.html Those are very specific cases, though. It doesn't mean that checked exceptions are bad in general. That same article explains why c.e. are a good feature of Java. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra)
[toc] | [prev] | [next] | [standalone]
| From | Kevin McMurtrie <mcmurtrie@pixelmemory.us> |
|---|---|
| Date | 2016-02-06 17:59 -0800 |
| Message-ID | <mcmurtrie-FB5BFE.17592406022016@news.sonic.net> |
| In reply to | #33629 |
In article <n9527l$ptu$2@dont-email.me>, 4ndre4 <4ndre4@4ndre4.com.invalid> wrote: > On 06/02/2016 15:01, Robert Klemme wrote: > [...] > >> Do you think this will scale? That's why JDBC has SQLException and > >> SpringFramework/JPA/Guice abandons checked exception altogether. > > > > I don't know why they did it. Can you provide any references to the > > reasoning of those projects to abandon checked exceptions? > > "Newer Java APIs such as the Spring Framework and the Java Data Objects > library have little or no reliance on checked exceptions. The Hibernate > ORM framework redefined key facilities as of release 3.0 to eliminate > the use of checked exceptions. This reflects the realization that the > great majority of the exception conditions that these frameworks report > are unrecoverable, stemming from incorrect coding of a method call, or a > failure of some underlying component such as a database server. > Practically speaking, there is almost no benefit to be gained by forcing > a caller to catch or declare such exceptions." - > http://www.oracle.com/technetwork/articles/entarch/effective-exceptions2-09704 > 4.html > > Those are very specific cases, though. It doesn't mean that checked > exceptions are bad in general. That same article explains why c.e. are a > good feature of Java. Lots of frameworks do away with checked exceptions because they can't be abstracted prior to Java 8. I'd not pay too much attention to what Oracle says. Their Java money is from "enterprise" features so convoluted that you need to hire their consultants to use them. I remember attending some Oracle tech talks where they're selling a new distributed server/monitoring/storage framework du jour that's as easy to set up as creating a hundred configuration files written in a proprietary XML structured language. I've used frameworks that turn everything into RuntimeExceptions. It's nice when you're in code that can't deal with exceptions. It's hell when you're in code that must handle specific exceptions and you can't see what's coming or from where. -- I will not see posts from astraweb, theremailer, dizum, or google because they host Usenet flooders.
[toc] | [prev] | [next] | [standalone]
| From | 4ndre4 <4ndre4@4ndre4.com.invalid> |
|---|---|
| Date | 2016-02-07 09:34 +0000 |
| Message-ID | <n972uf$rm0$6@dont-email.me> |
| In reply to | #33636 |
On 07/02/2016 01:59, Kevin McMurtrie wrote: [...] > I'd not pay too much attention to what Oracle says. Have you read the article? -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) "Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - http://goo.gl/1nrkkX
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:23 -0800 |
| Message-ID | <8b71526f-54c9-48a9-a7a7-522c1160b04a@googlegroups.com> |
| In reply to | #33636 |
On Saturday, 6 February 2016 21:05:24 UTC-5, Kevin McMurtrie wrote: > In article <n9527l$ptu$2@dont-email.me>, > 4ndre4 <4ndre4@4ndre4.com.invalid> wrote: > > > On 06/02/2016 15:01, Robert Klemme wrote: > > [...] > > >> Do you think this will scale? That's why JDBC has SQLException and > > >> SpringFramework/JPA/Guice abandons checked exception altogether. > > > > > > I don't know why they did it. Can you provide any references to the > > > reasoning of those projects to abandon checked exceptions? > > > > "Newer Java APIs such as the Spring Framework and the Java Data Objects > > library have little or no reliance on checked exceptions. The Hibernate > > ORM framework redefined key facilities as of release 3.0 to eliminate > > the use of checked exceptions. This reflects the realization that the > > great majority of the exception conditions that these frameworks report > > are unrecoverable, stemming from incorrect coding of a method call, or a > > failure of some underlying component such as a database server. > > Practically speaking, there is almost no benefit to be gained by forcing > > a caller to catch or declare such exceptions." - > > http://www.oracle.com/technetwork/articles/entarch/effective-exceptions2-09704 > > 4.html > > > > Those are very specific cases, though. It doesn't mean that checked > > exceptions are bad in general. That same article explains why c.e. are a > > good feature of Java. > > Lots of frameworks do away with checked exceptions because they can't be > abstracted prior to Java 8. > > I'd not pay too much attention to what Oracle says. Their Java money is > from "enterprise" features so convoluted that you need to hire their > consultants to use them. I remember attending some Oracle tech talks > where they're selling a new distributed server/monitoring/storage > framework du jour that's as easy to set up as creating a hundred > configuration files written in a proprietary XML structured language. > > I've used frameworks that turn everything into RuntimeExceptions. It's > nice when you're in code that can't deal with exceptions. It's hell > when you're in code that must handle specific exceptions and you can't > see what's coming or from where. > > -- > I will not see posts from astraweb, theremailer, dizum, or google > because they host Usenet flooders. so when you use frameworks as most of us do, how do you get the checked exceptions propagated so you can handle the specific exception?
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 20:52 -0800 |
| Message-ID | <5b9a671a-8825-4115-a811-93ded0a36e3f@googlegroups.com> |
| In reply to | #33629 |
On Saturday, 6 February 2016 10:10:36 UTC-5, 4ndre4 wrote: > On 06/02/2016 15:01, Robert Klemme wrote: > [...] > >> Do you think this will scale? That's why JDBC has SQLException and > >> SpringFramework/JPA/Guice abandons checked exception altogether. > > > > I don't know why they did it. Can you provide any references to the > > reasoning of those projects to abandon checked exceptions? > > "Newer Java APIs such as the Spring Framework and the Java Data Objects > library have little or no reliance on checked exceptions. The Hibernate > ORM framework redefined key facilities as of release 3.0 to eliminate > the use of checked exceptions. This reflects the realization that the > great majority of the exception conditions that these frameworks report > are unrecoverable, stemming from incorrect coding of a method call, or a > failure of some underlying component such as a database server. > Practically speaking, there is almost no benefit to be gained by forcing > a caller to catch or declare such exceptions." - > http://www.oracle.com/technetwork/articles/entarch/effective-exceptions2-097044.html > > Those are very specific cases, though. It doesn't mean that checked > exceptions are bad in general. That same article explains why c.e. are a > good feature of Java. > > -- > 4ndre4 > "The use of COBOL cripples the mind; its teaching should, therefore, be > regarded as a criminal offense." (E. Dijkstra) thanks for the article. It has a couple of interesting points. Particularly about IOException. But it is essentially still supporting checked exception. In the article, the author just calls runtime exception "fault" and checked exception "contingency". But one layer's contingency can be another layer's fault. I am sure when Java library authors wrote those "throws IOException", they expected the client knows how to handle them. That might be true if the client's call stack is just one level deep, so the client code must deal with it, even so, in most cases the best the client can do is to log it as with all other exceptions. But usually the method invoking the library call may be many call stacks deep down and it does not know how to handle the exception either, but still it should pass the exception back up the call chain hopefully at some level the exception can be handled. Passing IOException backup the call chain? It may not be possbile, due to: 1. one the call stack might implement an interface that does not allow checked exception or only certain type of exception; 2. as the call stack rewinds, the throws clause grows exponentially so it is no longer practical. Some one might suggest wrapping, but once you wrap, the benefit of checked exception completely diminishes: 1. you can't catch that exception any more, you have to catch the wrapped exception, then find the cause, or the cause of the cause, or the cause of the cause of the cause, ..., code gets messy very quickly; 2. you method throws clause now throws an obscure exception, your client can't figure out by just looking at its signature alone. Another reason that library authors should not dictate if the exceptions thrown from their libraries should be handled is that they don't have the information to make this decision. Only the client has the information to decide if the exception is fault or contingency. For example, if a method createDirectory() throws DirectoryAlreadyExistsExcetpion, for one client it is almost never going to happen (so it is fault), but for a client that relies on a known directory as a lock, that exception can be hanled (so it is a contingency) to reliably preventing concurrency (you can't check if the directory exists and then create, that leads to concurrency problem). When you are not in a position to predict/dictate and you predict/dictate, the result is chaos.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 21:13 -0800 |
| Message-ID | <ea8f99a2-9a83-4904-ab48-2c8746ce4eef@googlegroups.com> |
| In reply to | #33629 |
On Saturday, 6 February 2016 10:10:36 UTC-5, 4ndre4 wrote: > On 06/02/2016 15:01, Robert Klemme wrote: > [...] > >> Do you think this will scale? That's why JDBC has SQLException and > >> SpringFramework/JPA/Guice abandons checked exception altogether. > > > > I don't know why they did it. Can you provide any references to the > > reasoning of those projects to abandon checked exceptions? > > "Newer Java APIs such as the Spring Framework and the Java Data Objects > library have little or no reliance on checked exceptions. The Hibernate > ORM framework redefined key facilities as of release 3.0 to eliminate > the use of checked exceptions. This reflects the realization that the > great majority of the exception conditions that these frameworks report > are unrecoverable, stemming from incorrect coding of a method call, or a > failure of some underlying component such as a database server. > Practically speaking, there is almost no benefit to be gained by forcing > a caller to catch or declare such exceptions." - > http://www.oracle.com/technetwork/articles/entarch/effective-exceptions2-097044.html > > Those are very specific cases, though. It doesn't mean that checked > exceptions are bad in general. That same article explains why c.e. are a > good feature of Java. > > -- > 4ndre4 > "The use of COBOL cripples the mind; its teaching should, therefore, be > regarded as a criminal offense." (E. Dijkstra) that article leads to this one: http://www.artima.com/intv/handcuffs2.html ======================= begin quote ======================================= Bill Venners: So you think the more common case is that callers don't explicitly handle exceptions in deference to a general catch clause further up the call stack? Anders Hejlsberg: It is funny how people think that the important thing about exceptions is handling them. That is not the important thing about exceptions. In a well-written application there's a ratio of *****ten to one*****, in my opinion, of *****try finally to try catch*****. Or in C#, using statements, which are like try finally. ======================= end quote ======================================= There are very few places where exception can be correctly handled. Most of the catches caused by checked exceptions are just logging or convert to an error message shown either in a dialog box or in response to a browser request. These are usually done at a very high level. Checked or unchecked really does not matter. A catch that wraps an exception only increases code bloat. Some catches swallows exception (or log and swallow in the middle of call stack). That's a lot worse than wrapping. I suggest every one reading this post go back to your projects and take a look at all your catch statements and see how many are not wrapping or swallow or logging.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:19 -0800 |
| Message-ID | <728b8b89-9c94-4d41-b794-3e797f34a8cd@googlegroups.com> |
| In reply to | #33628 |
On Saturday, 6 February 2016 10:02:03 UTC-5, Robert Klemme wrote: > On 06.02.2016 01:09, b...@gmail.com wrote: > > On Friday, 5 February 2016 11:47:16 UTC-5, Eric Douglas wrote: > >> On Friday, February 5, 2016 at 11:26:04 AM UTC-5, box...@gmail.com wrote: > >>> 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". > >>> > >>> In application server case, usually most exceptions are just logged by the application server so that the application (and server) does not crash on an exception. There are very limited an app can do on most exceptions, like network outage, file accidentally removed, data accidentally removed from db, or due to bugs, these would usually require human intervention (fix network outage, put file back, fix data, fix bug etc). > >> > >> You still don't get it, and you still have yet to show a good example of how what you perceive to be a problem should be solved. > >> How can any method "not be forced to handle" any exception? If method3 calls method2 which calls method1 and method1 encounters an exception do you think the norm should be to log the exception and continue as if nothing is wrong, or how do you propose method1 should tell method3 about the problem without telling method2? It could throw an unchecked exception, which method2 wouldn't have to do anything for and method3 could still catch, but the programmer writing method3 still needs to know about the possibility of this exception and code for it. It sounds like you're just making the huge assumption that causes many of the program errors in any language, that every programmer just knows every possible runtime error and writes handlers for them. > > > > As you said, if a runtime exception is thrown from method1 and method2 does not know how to handle it, method2 does not need to do anything and method3 can still catch that exception and handle it. The developer need know method2 might throw this exception. I am afraid we can not rely on checked exception to document this exception. Why? Suppose we have > > > > method3 calls method2a and method2b and method2c > > method2a calls method1a1 and method1a2 and method1a3 > > method2b calls method1b1 and mehtod1b2 and method1b3 > > method2c calls method1c1 and mehtod1c2 and method1c3 > > and each method1xy throws one exception say Exception1xy > > now method3 signature would be > > method3(...)throws Exception1a1, Exception1ab, Exception1a3, Exception1b1, Exception1b2, Exception1b3, Exception1c1, Exception1c2, Exception1c3 > > > > Do you think this will scale? That's why JDBC has SQLException and SpringFramework/JPA/Guice abandons checked exception altogether. > > I don't know why they did it. Can you provide any references to the > reasoning of those projects to abandon checked exceptions? the rational is exactly I stated in my blog. > > > This is only 3 levels, enterprise applications sometimes have 20+ levels. the throws clause would grow exponentially for each method. Soon the code would be nothing but exceptions! > > This is silly - for a number of reasons: > - all intermediate methods can choose what exception to catch > themselves and what they throw. > - they can especially choose to throw another exception type wrapping > the original one. > - inheritance also works for exceptions > > Hiding exception conditions does not make all the ways go away in which > various functionalities can fail. You need flexible and robust ways to > handle them. That's what you get with exceptions. throwing runtime exception is not hiding. Wrapping exception or exception inheritance obscures the exception and defeats the purpose of checked exception because you have to dig into cause or find child exception type to know how to deal with it. Once you do that, it's worse than runtime exception because you have to do all the extra wrapping unwrapping, finding child type etc. It's better to have the exception info as is but checked exception makes it impossible to do so. > > Cheers > > robert > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-07 23:42 +0000 |
| Message-ID | <n98kot$rpt$3@dont-email.me> |
| In reply to | #33649 |
On Sun, 07 Feb 2016 14:19:53 -0800, boxzou wrote: > On Saturday, 6 February 2016 10:02:03 UTC-5, Robert Klemme wrote: >> I don't know why they did it. Can you provide any references to the >> reasoning of those projects to abandon checked exceptions? > the rational is exactly I stated in my blog. > Does this mean that you don't know why or merely that you can't be arsed to find out? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2016-02-08 13:17 +0100 |
| Message-ID | <dhrfbkFae81U1@mid.individual.net> |
| In reply to | #33649 |
On 07.02.2016 23:19, boxzou@gmail.com wrote: > On Saturday, 6 February 2016 10:02:03 UTC-5, Robert Klemme wrote: >> On 06.02.2016 01:09, b...@gmail.com wrote: >> I don't know why they did it. Can you provide any references to the >> reasoning of those projects to abandon checked exceptions? > the rational is exactly I stated in my blog. Come one. You must understand that it is something else that you claim they follow your argument than reading what they wrote themselves. Since you want to make the point against checked exception the burden is on you to provide backing arguments. >>> This is only 3 levels, enterprise applications sometimes have 20+ levels. the throws clause would grow exponentially for each method. Soon the code would be nothing but exceptions! >> >> This is silly - for a number of reasons: >> - all intermediate methods can choose what exception to catch >> themselves and what they throw. >> - they can especially choose to throw another exception type wrapping >> the original one. >> - inheritance also works for exceptions >> >> Hiding exception conditions does not make all the ways go away in which >> various functionalities can fail. You need flexible and robust ways to >> handle them. That's what you get with exceptions. > throwing runtime exception is not hiding. Wrapping exception or > exception inheritance obscures the exception and defeats the purpose > of checked exception because you have to dig into cause or find child > exception type to know how to deal with it. Once you do that, it's > worse than runtime exception because you have to do all the extra > wrapping unwrapping, finding child type etc. It's better to have the > exception info as is but checked exception makes it impossible to do > so. There are various ways to go about things and unfortunately that does not fit well with the "X is good / bad" approach you are taking. 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). Abandoning a useful feature just because of some minor disadvantages does not show good judgment. Eventually it is all about trade offs. Your radical approach suggests that you do not embrace that concept. Good luck! robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 04:39 -0800 |
| Message-ID | <83011e99-7f61-4f02-8cba-2f2c9107d8ee@googlegroups.com> |
| In reply to | #33668 |
On Monday, 8 February 2016 07:18:08 UTC-5, Robert Klemme wrote: > On 07.02.2016 23:19, b...@gmail.com wrote: > > On Saturday, 6 February 2016 10:02:03 UTC-5, Robert Klemme wrote: > >> On 06.02.2016 01:09, b...@gmail.com wrote: > > >> I don't know why they did it. Can you provide any references to the > >> reasoning of those projects to abandon checked exceptions? > > the rational is exactly I stated in my blog. > > Come one. You must understand that it is something else that you claim > they follow your argument than reading what they wrote themselves. > Since you want to make the point against checked exception the burden is > on you to provide backing arguments. > > >>> This is only 3 levels, enterprise applications sometimes have 20+ levels. the throws clause would grow exponentially for each method. Soon the code would be nothing but exceptions! > >> > >> This is silly - for a number of reasons: > >> - all intermediate methods can choose what exception to catch > >> themselves and what they throw. > >> - they can especially choose to throw another exception type wrapping > >> the original one. > >> - inheritance also works for exceptions > >> > >> Hiding exception conditions does not make all the ways go away in which > >> various functionalities can fail. You need flexible and robust ways to > >> handle them. That's what you get with exceptions. > > throwing runtime exception is not hiding. Wrapping exception or > > exception inheritance obscures the exception and defeats the purpose > > of checked exception because you have to dig into cause or find child > > exception type to know how to deal with it. Once you do that, it's > > worse than runtime exception because you have to do all the extra > > wrapping unwrapping, finding child type etc. It's better to have the > > exception info as is but checked exception makes it impossible to do > > so. > > There are various ways to go about things and unfortunately that does > not fit well with the "X is good / bad" approach you are taking. > > 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). Abandoning a useful feature just > because of some minor disadvantages does not show good judgment. > Eventually it is all about trade offs. Your radical approach suggests > that you do not embrace that concept. > > Good luck! > > robert > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing.
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-02-08 16:05 -0800 |
| Message-ID | <fda72a96-d611-4be9-a2db-c3123f62cdee@googlegroups.com> |
| In reply to | #33670 |
On Monday, February 8, 2016 at 4:39:48 AM UTC-8, box...@gmail.com wrote: > Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing. What does "how few meaning catches there are" mean? Logging is critical when you hit an exception. Your statement hints that you think that is not useful. If that is the claim, it is not very pragmatic. Logging occurs in all my exception handlers. 100%. Swallowing exceptions is never a good thing, and contrary to best practices for exception handling, so in my code that is zero percent. 0%. Wrapping exceptions is very rare in my code, < 1%. Throwing exceptions is common in my code. For example, if an invariant is not met I might throw an 'IllegalStateException' right before the assertion that it is met. As the invariant violation is a programming error, it gets a runtime exception. If it were a predictable out-of-band condition that is not a programmer error, and it is in a type that I can modify, I'd declare a checked exception. Handling exceptions is the prevalent idiom in my exception handlers. Log, then return the program to a valid state. Not wrapped, not swallowed, but handled. > 99%. But then again, I understand and appreciate Java exceptions, both checked and unchecked. And your point is ...? -- Lew
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 18:35 -0800 |
| Message-ID | <5596dea3-275c-4655-acd0-d1f0ea2a208a@googlegroups.com> |
| In reply to | #33695 |
On Monday, 8 February 2016 19:05:48 UTC-5, Lew wrote: > On Monday, February 8, 2016 at 4:39:48 AM UTC-8, box...@gmail.com wrote: > > Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing. > > What does "how few meaning catches there are" mean? > sorry I meant how few ***meaningful*** catches ... > Logging is critical when you hit an exception. Your statement hints that you think that is not useful. If that is the claim, it is not very pragmatic. > Yes logging is very important. but you don't need checked exception for logging. > Logging occurs in all my exception handlers. 100%. > Logging should only be done if the exception can't be handled or rethrown. Otherwise log file is littered with the same exception logged multiple times. It is better than swallowing but still annoying. This is another problem of checked exception. > Swallowing exceptions is never a good thing, and contrary to best practices for exception handling, so in my code that is zero percent. 0%. > Great! > Wrapping exceptions is very rare in my code, < 1%. > so you always list your exception in the throws clause? what's the maximum number of exceptions do you list there? I see some developers in the end just do "throws Exception". > Throwing exceptions is common in my code. For example, if an invariant is not met I might throw an 'IllegalStateException' right before the assertion that it is met. As the invariant violation is a programming error, it gets a runtime exception. If it were a predictable out-of-band condition that is not a programmer error, and it is in a type that I can modify, I'd declare a checked exception. > > Handling exceptions is the prevalent idiom in my exception handlers. Log, then return the program to a valid state. Not wrapped, not swallowed, but handled. > 99%. > very impressive. Have you really gone through your code in such short time? When I checked our code, it took me a few days. We currently have 4736 java files including tests. > But then again, I understand and appreciate Java exceptions, both checked and unchecked. > > And your point is ...? > my point is checked exception causes so much unnecessary catches, leading to code bloat and introducing lots of bugs (mode code --> more bugs).
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 19:10 -0800 |
| Message-ID | <f9ad0035-532c-49b2-ae37-ebef6962007d@googlegroups.com> |
| In reply to | #33701 |
On Monday, 8 February 2016 21:35:33 UTC-5, box...@gmail.com wrote:
> On Monday, 8 February 2016 19:05:48 UTC-5, Lew wrote:
> > On Monday, February 8, 2016 at 4:39:48 AM UTC-8, box...@gmail.com wrote:
> > > Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing.
> >
> > What does "how few meaning catches there are" mean?
> >
> sorry I meant how few ***meaningful*** catches ...
>
> > Logging is critical when you hit an exception. Your statement hints that you think that is not useful. If that is the claim, it is not very pragmatic.
> >
> Yes logging is very important. but you don't need checked exception for logging.
>
> > Logging occurs in all my exception handlers. 100%.
> >
> Logging should only be done if the exception can't be handled or rethrown. Otherwise log file is littered with the same exception logged multiple times. It is better than swallowing but still annoying. This is another problem of checked exception.
>
> > Swallowing exceptions is never a good thing, and contrary to best practices for exception handling, so in my code that is zero percent. 0%.
> >
> Great!
>
> > Wrapping exceptions is very rare in my code, < 1%.
> >
> so you always list your exception in the throws clause? what's the maximum number of exceptions do you list there? I see some developers in the end just do "throws Exception".
>
> > Throwing exceptions is common in my code. For example, if an invariant is not met I might throw an 'IllegalStateException' right before the assertion that it is met. As the invariant violation is a programming error, it gets a runtime exception. If it were a predictable out-of-band condition that is not a programmer error, and it is in a type that I can modify, I'd declare a checked exception.
> >
> > Handling exceptions is the prevalent idiom in my exception handlers. Log, then return the program to a valid state. Not wrapped, not swallowed, but handled. > 99%.
> >
> very impressive. Have you really gone through your code in such short time? When I checked our code, it took me a few days. We currently have 4736 java files including tests.
>
> > But then again, I understand and appreciate Java exceptions, both checked and unchecked.
> >
> > And your point is ...?
> >
> my point is checked exception causes so much unnecessary catches, leading to code bloat and introducing lots of bugs (mode code --> more bugs).
Here is the statistics from our code base a few months ago. Remember I have tried my best to use runtime exceptions but unfortunately a lot of developers still created many checked exceptions. The stats does not include test classes. There are 2 major components (comp1 and comp2). I own part of comp1. EclipseLink 2.4.2 is shown for some reference.
comp1 comp2 EclipseLink 2.4.2
type of exception used checked/uncheck mixed mostly checked strictly unchecked
java class files 974 1141 3113
lines 111,619 201,640 241,530
bytes 4,194,569 7,991,940 9,726,473
total catches 934 1346 2851
catch/file 0.96 1.18 0.92
======================== wrap/rethrow ======================================
convert to RuntimeException 105 155
convert to other Exception 189 183
printStackTrace() 35 113
rethrow 18 7
can be eliminated 4 12
+ NException.convert() 134 2
sub total 485 472
============ below redundant logging can be eliminated =====================
log message + stack trace 119 391
log only message 59 108
sub total 178 499
========== above are bad ex handling, below are good =======================
+ handle other than logging 108 69 <-- we'll focus on this one
+ chain (use code) 13 N/A
+ terminal error 3 N/A
+ ignore Throwable (log) 52 N/A
+ terminal logging 14 N/A
sub total 190 69
- validation 14 84
- bury 65 131 <-- this is bad!
As you can see for comp1, a lot of catches were dedicated to wrapping (485 / 934 > 50%). There are a lot of redundant logging (178 /934 ~ 18%). Meaningful handling + necessary logging only account about less than 20% of all catches.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 19:12 -0800 |
| Message-ID | <50abe57a-bef5-4efd-9df7-7d1f1180aeef@googlegroups.com> |
| In reply to | #33701 |
On Monday, 8 February 2016 21:35:33 UTC-5, box...@gmail.com wrote: > On Monday, 8 February 2016 19:05:48 UTC-5, Lew wrote: > > On Monday, February 8, 2016 at 4:39:48 AM UTC-8, box...@gmail.com wrote: > > > Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing. > > > > What does "how few meaning catches there are" mean? > > > sorry I meant how few ***meaningful*** catches ... > > > Logging is critical when you hit an exception. Your statement hints that you think that is not useful. If that is the claim, it is not very pragmatic. > > > Yes logging is very important. but you don't need checked exception for logging. > > > Logging occurs in all my exception handlers. 100%. > > > Logging should only be done if the exception can't be handled or rethrown. Otherwise log file is littered with the same exception logged multiple times. It is better than swallowing but still annoying. This is another problem of checked exception. > > > Swallowing exceptions is never a good thing, and contrary to best practices for exception handling, so in my code that is zero percent. 0%. > > > Great! > > > Wrapping exceptions is very rare in my code, < 1%. > > > so you always list your exception in the throws clause? what's the maximum number of exceptions do you list there? I see some developers in the end just do "throws Exception". > > > Throwing exceptions is common in my code. For example, if an invariant is not met I might throw an 'IllegalStateException' right before the assertion that it is met. As the invariant violation is a programming error, it gets a runtime exception. If it were a predictable out-of-band condition that is not a programmer error, and it is in a type that I can modify, I'd declare a checked exception. > > > > Handling exceptions is the prevalent idiom in my exception handlers. Log, then return the program to a valid state. Not wrapped, not swallowed, but handled. > 99%. > > > very impressive. Have you really gone through your code in such short time? When I checked our code, it took me a few days. We currently have 4736 java files including tests. > > > But then again, I understand and appreciate Java exceptions, both checked and unchecked. > > > > And your point is ...? > > > my point is checked exception causes so much unnecessary catches, leading to code bloat and introducing lots of bugs (mode code --> more bugs). correct typo. (***more*** code --> more bugs)
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-11 16:37 +0100 |
| Message-ID | <56bcaad1$0$23816$e4fe514c@news.xs4all.nl> |
| In reply to | #33695 |
On 02/09/2016 01:05 AM, Lew wrote: > On Monday, February 8, 2016 at 4:39:48 AM UTC-8, box...@gmail.com wrote: >> Please search for catch in your code to see how few meaning catches there are other than logging/wrapping/swallowing. > > What does "how few meaning catches there are" mean? > > Logging is critical when you hit an exception. Your statement hints that you think that is not useful. If that is the claim, it is not very pragmatic. > > Logging occurs in all my exception handlers. 100%. > > Swallowing exceptions is never a good thing, and contrary to best practices for exception handling, so in my code that is zero percent. 0%. > > Wrapping exceptions is very rare in my code, < 1%. > > Throwing exceptions is common in my code. For example, if an invariant is not met I might throw an 'IllegalStateException' right before the assertion that it is met. As the invariant violation is a programming error, it gets a runtime exception. If it were a predictable out-of-band condition that is not a programmer error, and it is in a type that I can modify, I'd declare a checked exception. > > Handling exceptions is the prevalent idiom in my exception handlers. Log, then return the program to a valid state. Not wrapped, not swallowed, but handled. > 99%. > > But then again, I understand and appreciate Java exceptions, both checked and unchecked. > > And your point is ...? > 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.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web