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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 11:10 -0800 |
| Message-ID | <94cd2881-e72e-45f6-a0ba-e4816a073bdc@googlegroups.com> |
| In reply to | #33581 |
I am a java programmer for 15 years (since 2001). How about you? On Thursday, 4 February 2016 11:15:58 UTC-5, Eric Douglas wrote: > Checked exception is the norm. How long have you been programming Java? > I can't imagine how anyone could "abandon checked exceptions" but I'm not familiar with the frameworks you mention. > > Normally an application has a try catch block for all possible checked excpetions, and sometimes it handles them differently while sometimes it doesn't care. > > If you're passing a file name into a method you need to know which exception it's getting. If it's a FileNotFound you might ask the user for a new file name. If it's a security exception you can tell the user they don't have rights to update that file. If it's an IOException maybe there was a network connection bug, maybe you want to just try again, or tell the user there was a problem and give them some options. > > For an example that doesn't care, my application API calls the pdfbox API to read an existing PDF file and render it to the screen. I catch every possible exception and just set a boolean return value for my method which just says it worked or not. While the pdfbox API throws a RunTimeException (which is not normally caught and crashes the application if you don't catch it) if there was a problem reading the PDF because of the security provider, I don't want that to crash. For all errors/exceptions reading/rendering the PDF I just send the PDF to the user to attempt to open with Adobe.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 11:28 -0800 |
| Message-ID | <1f530432-5d7f-427c-a8bf-d7818d97a4c2@googlegroups.com> |
| In reply to | #33586 |
On Thursday, February 4, 2016 at 2:11:19 PM UTC-5, box...@gmail.com wrote: > I am a java programmer for 15 years (since 2001). How about you? Highly doubtful, but if so then surely you should know how to make a real point with details, code samples showing what you don't like and what you think it should look like, instead of trolling wild accusations. Apparently any fool can get a blog.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 11:33 -0800 |
| Message-ID | <1709a4c8-8ce7-426f-92c3-8a16371326ad@googlegroups.com> |
| In reply to | #33588 |
On Thursday, 4 February 2016 14:28:25 UTC-5, Eric Douglas wrote: > On Thursday, February 4, 2016 at 2:11:19 PM UTC-5, box...@gmail.com wrote: > > I am a java programmer for 15 years (since 2001). How about you? > > Highly doubtful, but if so then surely you should know how to make a real point with details, code samples showing what you don't like and what you think it should look like, instead of trolling wild accusations. Apparently any fool can get a blog. I think you don't know what you're talking about.
[toc] | [prev] | [next] | [standalone]
| From | 4ndre4 <4ndre4@4ndre4.com.invalid> |
|---|---|
| Date | 2016-02-04 21:08 +0000 |
| Message-ID | <n90eer$gpl$2@dont-email.me> |
| In reply to | #33589 |
On 04/02/2016 19:33, boxzou@gmail.com wrote: [...] > I think you don't know what you're talking about. Exactly what I thought after reading your "article". -- 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 | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-02-04 16:09 -0800 |
| Message-ID | <8ec677c7-49d0-4f0a-9f49-3b972aa183b6@googlegroups.com> |
| In reply to | #33589 |
On Thursday, February 4, 2016 at 11:35:52 AM UTC-8, box...@gmail.com wrote: > On Thursday, 4 February 2016 14:28:25 UTC-5, Eric Douglas wrote: > > On Thursday, February 4, 2016 at 2:11:19 PM UTC-5, box...@gmail.com wrote: > > > I am a java programmer for 15 years (since 2001). How about you? > > > > Highly doubtful, but if so then surely you should know how to make a real point with details, code samples showing what you don't like and what you think it should look like, instead of trolling wild accusations. Apparently any fool can get a blog. > > I think you don't know what you're talking about. That is the typical response of someone who has nothing to support their argument, so they insult anyone who challenges their "genius". I wouldn't waste the two seconds it takes to click on your link, let alone read your thesis, now that I know how you operate. By the way, checked exceptions are GOOD! You clearly do not understand their utility. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-04 12:00 -0500 |
| Message-ID | <n8vvto$ol5$1@dont-email.me> |
| In reply to | #33580 |
On 2/4/2016 10:18 AM, boxzou@gmail.com wrote:
> http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
>
> In the above link I proved in theory why checked exception is BAD.
I have seldom encountered a proof as rigorous as yours: Every step
follows immediately from its predecessors, and the initial step is
solidly grounded on the axioms of Universal Truth. Donald Trump
Himself could not have done better.
Thanks to your proof, we now understand why nobody uses Java.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2016-02-04 19:28 +0100 |
| Message-ID | <n90595$a29$1@gwaiyur.mb-net.net> |
| In reply to | #33580 |
On 04.02.16 16.18, boxzou@gmail.com wrote: > In the above link I proved in theory why checked exception is BAD. > > It's sad to see that even though checked exceptions have been proven a mistake in practice and abandoned by major software packages like Spring Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a guideline on the official java tutorial: Well, if you dislike runtime checks choose an interpreter language like Python or Perl. You probably will like bugs after that. > This is totally misinformation! Checked exception is a mistake. It should be rid of from Java (luckily no other language has this concept). So, C++ is no language? Neither ABAP Objects is? Marcel
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 11:15 -0800 |
| Message-ID | <80d64024-65d9-4375-987d-c29eafa67b09@googlegroups.com> |
| In reply to | #33585 |
On Thursday, 4 February 2016 13:29:15 UTC-5, Marcel Mueller wrote: > Well, if you dislike runtime checks choose an interpreter language like > Python or Perl. You probably will like bugs after that. > > > This is totally misinformation! Checked exception is a mistake. It should be rid of from Java (luckily no other language has this concept). > > So, C++ is no language? Neither ABAP Objects is? > > > Marcel Exception is good, but Checked exception is BAD!
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-04 14:51 -0500 |
| Message-ID | <n909ud$3g3$1@dont-email.me> |
| In reply to | #33587 |
On 2/4/2016 2:15 PM, boxzou@gmail.com wrote:
> On Thursday, 4 February 2016 13:29:15 UTC-5, Marcel Mueller wrote:
>> Well, if you dislike runtime checks choose an interpreter language like
>> Python or Perl. You probably will like bugs after that.
>>
>>> This is totally misinformation! Checked exception is a mistake. It should be rid of from Java (luckily no other language has this concept).
>>
>> So, C++ is no language? Neither ABAP Objects is?
>>
>>
>> Marcel
>
> Exception is good, but Checked exception is BAD!
... and you've PROVED it!!!
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | 4ndre4 <4ndre4@4ndre4.com.invalid> |
|---|---|
| Date | 2016-02-04 21:07 +0000 |
| Message-ID | <n90ecc$gpl$1@dont-email.me> |
| In reply to | #33580 |
On 04/02/2016 15:18, boxzou@gmail.com wrote: [...] > http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html > > In the above link I proved in theory why checked exception is BAD. Erm... I was expecting a much longer and much more enlightening disseration. You have just repeated some of the known flaws of checked exceptions without saying anything really new. In his item #59, Joshua Bloch[1] says "Checked exceptions are a wonderful feature of the Java programming language. Unlike return codes, they force the programmer to deal with exceptional conditions, greatly enhancing reliability. That said, overuse of checked exceptions can make an API far less pleasant to use." and he goes on explaining the reasons why you shouldn't overusethem. You'd better read that book. You say "Exception is supposed to be handled exceptionally, i.e. rarely. But checked exception contradicts this principle by forcing the caller to handle it right after a method call" I don't think that forcing the developer to handle the exception is a contradiction of the principle that exceptions should be handled exceptionally. What you, as a developer, are required to provide, is some code that deals with the exception in those (supposedly) rare case when it will happen. "it turns really ugly to see 3 or more exceptions" If you're method is throwing too many exceptions, it is likely that your method is doing more than it is supposed to do. "And any non-trivial software system would have far more than 3 exceptional conditions!" Supposedly not thrown by the same method. [1] Effective Java, 2nd ed., p.246. -- 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 | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 14:36 -0800 |
| Message-ID | <df61bc82-031d-48bc-8c5f-597c84b18f6c@googlegroups.com> |
| In reply to | #33597 |
On Thursday, 4 February 2016 16:07:16 UTC-5, 4ndre4 wrote: > On 04/02/2016 15:18, boxzou@gmail.com wrote: > > [...] > > http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html > > > > In the above link I proved in theory why checked exception is BAD. > > Erm... I was expecting a much longer and much more enlightening > disseration. You have just repeated some of the known flaws of checked > exceptions without saying anything really new. > > In his item #59, Joshua Bloch[1] says "Checked exceptions are a > wonderful feature of the Java programming language. > Unlike return codes, they force the programmer to deal with exceptional > conditions, greatly enhancing reliability. That said, overuse of checked > exceptions can make an API far less pleasant to use." and he goes on > explaining the reasons why you shouldn't overusethem. > > You'd better read that book. > > You say "Exception is supposed to be handled exceptionally, i.e. rarely. > But checked exception contradicts this principle by forcing the caller > to handle it right after a method call" > > I don't think that forcing the developer to handle the exception is a > contradiction of the principle that exceptions should be handled > exceptionally. What you, as a developer, are required to provide, is > some code that deals with the exception in those (supposedly) rare case > when it will happen. > > "it turns really ugly to see 3 or more exceptions" > > If you're method is throwing too many exceptions, it is likely that your > method is doing more than it is supposed to do. > > "And any non-trivial software system would have far more than 3 > exceptional conditions!" > > Supposedly not thrown by the same method. > > [1] Effective Java, 2nd ed., p.246. > > -- > 4ndre4 > "The use of COBOL cripples the mind; its teaching should, therefore, be > regarded as a criminal offense." (E. Dijkstra) thank you for your suggestion. Effective Java has many wonderful practices. But #59 is definitely wrong. That's what I tried to prove. In JPA, EntityManager.persist(Object obj) which stores the obj into database tables. Database can be network-based or file-based or memory-based. It opens jdbc connection which opens socket connection, or may open a file, read/write to socket, jdbc might check some constraints and throws all kinds of exceptions back (yes SQLException, but it has thousands of different kinds of error code). It can not "throws" all these exceptions. So the expert made the right choice in JPA: they decided to use unchecked exception. It did not make JPA worse. It actually makes JPA much better: cleaner/less code. A lot of enterprises depend on JPA.
[toc] | [prev] | [next] | [standalone]
| From | a.laforgia@gmail.com |
|---|---|
| Date | 2016-02-05 05:28 -0800 |
| Message-ID | <699ccb9d-3e91-4903-aefe-a1d7dc025430@googlegroups.com> |
| In reply to | #33603 |
On Thursday, 4 February 2016 22:36:14 UTC, box...@gmail.com wrote: [...] > #59 is definitely wrong. That's what I tried to prove. I don't think you proved Bloch's wrong, also because your blog article is just something along the lines "I don't like checked exceptions, therefore I've proved that checked exceptions are wrong". I think you haven't understood what checked exceptions are for. I suggest that you read this: http://www.oracle.com/au/products/database/effective-exceptions-092345.html
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 15:31 -0800 |
| Message-ID | <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com> |
| In reply to | #33580 |
On Thursday, 4 February 2016 10:19:27 UTC-5, box...@gmail.com wrote: > http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html > > In the above link I proved in theory why checked exception is BAD. > > It's sad to see that even though checked exceptions have been proven a mistake in practice and abandoned by major software packages like Spring Framework/Guice/EclipseLink/Hibernate etc, the following is still listed as a guideline on the official java tutorial: > > https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html > ==================== begin quote =============================================== > Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. > ==================== end quote =============================================== > > This is totally misinformation! Checked exception is a mistake. It should be rid of from Java (luckily no other language has this concept). Maybe I was not clear in the blog. I think all problems with Checked Exception arise from the following contradiction: 1. Exception should be handled rarely, vs 2. Exception must be handled (either catch or throws). Do not think throws is so simple. It creates a lot of problems as witnessed by Bruce Eckel, Rod Waldhoff and Alan Griffiths and many others.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-05 08:20 -0500 |
| Message-ID | <n927ep$3j2$1@dont-email.me> |
| In reply to | #33606 |
On 2/4/2016 6:31 PM, boxzou@gmail.com wrote:
> [...]
> Maybe I was not clear in the blog. I think all problems with Checked Exception arise from the following contradiction:
>
> 1. Exception should be handled rarely, vs
> 2. Exception must be handled (either catch or throws).
If code is to be reliable, (1) cannot hold: Exceptional conditions
that arise (however they are reported) must be handled in some fashion.
You cannot simply ignore them except in rare cases, you must always make
some kind of provision for failures.
Sometimes the appropriate response to failure (some kinds, anyhow)
is to "fail fast and hard" as another poster recommends. Sometimes the
response should be to pass the buck: "I'm reporting a failure because a
lower level reported failure to me." Sometimes the response should be
to cancel an operation in progress (e.g., don't commit the DB update),
or to ask for outside help (e.g., show a dialog explaining that a user-
provided URL doesn't respond). Sometimes it's a combination of these
strategies (cancel the DB commit and then pass the buck).
But coping with an error "rarely," if you just happened to be in a
merry mood the day you wrote the code, is a recipe for failure. Errors
*will* occur, even if they occur only once per million executions, and
the code *must* do *something* in response.
--
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-05 08:25 -0800 |
| Message-ID | <c1b3b4c8-2481-48fa-b4ad-9fcde6333811@googlegroups.com> |
| In reply to | #33614 |
On Friday, 5 February 2016 08:21:19 UTC-5, Eric Sosman wrote: > On 2/4/2016 6:31 PM, b...@gmail.com wrote: > > [...] > > Maybe I was not clear in the blog. I think all problems with Checked Exception arise from the following contradiction: > > > > 1. Exception should be handled rarely, vs > > 2. Exception must be handled (either catch or throws). > > If code is to be reliable, (1) cannot hold: Exceptional conditions > that arise (however they are reported) must be handled in some fashion. > You cannot simply ignore them except in rare cases, you must always make > some kind of provision for failures. > > Sometimes the appropriate response to failure (some kinds, anyhow) > is to "fail fast and hard" as another poster recommends. Sometimes the > response should be to pass the buck: "I'm reporting a failure because a > lower level reported failure to me." Sometimes the response should be > to cancel an operation in progress (e.g., don't commit the DB update), > or to ask for outside help (e.g., show a dialog explaining that a user- > provided URL doesn't respond). Sometimes it's a combination of these > strategies (cancel the DB commit and then pass the buck). > > But coping with an error "rarely," if you just happened to be in a > merry mood the day you wrote the code, is a recipe for failure. Errors > *will* occur, even if they occur only once per million executions, and > the code *must* do *something* in response. > > -- > esosman@comcast-dot-net.invalid > "Don't be afraid of work. Make work afraid of you." -- TLM 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).
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-05 08:47 -0800 |
| Message-ID | <4deef389-ea5b-483a-bff5-4e1bdd45de2e@googlegroups.com> |
| In reply to | #33617 |
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.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-05 16:09 -0800 |
| Message-ID | <2b736fcd-b72c-49b5-b4b8-9657ecebd51e@googlegroups.com> |
| In reply to | #33618 |
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. 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!
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-06 08:38 -0500 |
| Message-ID | <n94sri$run$1@dont-email.me> |
| In reply to | #33621 |
On 2/5/2016 7:09 PM, boxzou@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
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-06 14:13 +0000 |
| Message-ID | <n94v2i$2b3$1@dont-email.me> |
| In reply to | #33623 |
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 |
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-06 15:23 +0100 |
| Message-ID | <56b601cc$0$23722$e4fe514c@news.xs4all.nl> |
| In reply to | #33624 |
On 02/06/2016 03:13 PM, 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? > > I would not say it is a bad approach and it is one common way people deal with checked exceptions. If one really buys into the concept one will consider your way of doing things bad. I consider it one of the plausible ways of working around checked exceptions to keep things manageable.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web