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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 07:18 -0800 |
| Subject | Java Checked Exception is BAD! |
| Message-ID | <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com> |
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).
[toc] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 08:15 -0800 |
| Message-ID | <3e5ccef4-d91a-4d66-be03-c8f0b58df128@googlegroups.com> |
| In reply to | #33580 |
On Thursday, February 4, 2016 at 10:19:27 AM 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). 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 | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-04 17:57 +0100 |
| Message-ID | <56b382dd$0$23867$e4fe514c@news.xs4all.nl> |
| In reply to | #33581 |
On 02/04/2016 05:15 PM, Eric Douglas wrote: > On Thursday, February 4, 2016 at 10:19:27 AM 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). > > 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. > I suppose you mean "the norm" in its limited meaning being "the norm in Java"? Note that Java is the only language that has checked exceptions. You make a case for exceptions in general and not for checked ones in particular. Unchecked exceptions can of course be caught based on their exact or generic type just like checked ones. In fact, checked exceptions only exist in the reasoning of the standard Java compiler. Everything else about exceptions is handled runtime. The JVM could not care less what exceptions a method might throw. Adding a boolean flag to the compiler that would disable the check would probably be quite trivial... Scala has ditched checked exceptions in favor of unchecked ones. And that language has been designed by the man who wrote the GJ compiler that formed the basis of the standard Java 1.3 compiler even before generics became part of the language. He had the hindsight advantage. Other languages that where developed after Java also chose to take the unchecked route. For good reasons. Most proponents I have met use mainly Java and are just used to doing it the checked way.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 10:09 -0800 |
| Message-ID | <b77a7d7f-5628-4900-a507-736a8354a381@googlegroups.com> |
| In reply to | #33582 |
On Thursday, February 4, 2016 at 11:57:16 AM UTC-5, Silvio wrote: > On 02/04/2016 05:15 PM, Eric Douglas wrote: > > On Thursday, February 4, 2016 at 10:19:27 AM 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). > > > > 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. > > > > I suppose you mean "the norm" in its limited meaning being "the norm in > Java"? Note that Java is the only language that has checked exceptions. > > You make a case for exceptions in general and not for checked ones in > particular. Unchecked exceptions can of course be caught based on their > exact or generic type just like checked ones. In fact, checked > exceptions only exist in the reasoning of the standard Java compiler. > Everything else about exceptions is handled runtime. The JVM could not > care less what exceptions a method might throw. > > Adding a boolean flag to the compiler that would disable the check would > probably be quite trivial... > > Scala has ditched checked exceptions in favor of unchecked ones. And > that language has been designed by the man who wrote the GJ compiler > that formed the basis of the standard Java 1.3 compiler even before > generics became part of the language. He had the hindsight advantage. > Other languages that where developed after Java also chose to take the > unchecked route. For good reasons. > > Most proponents I have met use mainly Java and are just used to doing it > the checked way. I mean the norm in Java as opposed to unchecked exceptions. Checked exceptions are better than unchecked ones, because if you have to trap for them regardless, the checked ones tell you what to look for. If everything is unchecked then every method you call from someone else's API that could possibly throw an error you have to remember to add a trap for to somehow avoid crashing your application. If it's going to throw an error that's going to bring my user to a halt it had better be something I consider critical and know no way around.
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-04 21:01 +0100 |
| Message-ID | <56b3ae12$0$23750$e4fe514c@news.xs4all.nl> |
| In reply to | #33584 |
On 02/04/2016 07:09 PM, Eric Douglas wrote: > > I mean the norm in Java as opposed to unchecked exceptions. > > Checked exceptions are better than unchecked ones, because if you have to trap for them regardless, the checked ones tell you what to look for. If everything is unchecked then every method you call from someone else's API that could possibly throw an error you have to remember to add a trap for to somehow avoid crashing your application. If it's going to throw an error that's going to bring my user to a halt it had better be something I consider critical and know no way around. > That is the theory and it is not bad at all. Nobody says the decision to try checked exceptions was made by stupid people and it was immediately obvious that it was a bad idea. Checked exceptions are viral not unlike the GPL. Every higher level in the call chain has to declare to throw the complete superset of all exceptions thrown in its children unless someone does one of the "smart moves" somewhere in there to hide exceptions in some way (throws Exception, catch-log-absorb, wrap in RuntimeException or any other misguided variant). The current consensus is that "fail fast and hard" is mostly better than laborious attempts for partial repairs at various levels. Checked exceptions promote the latter and make the former very hard. That with the fact that exceptions are highly overused in the standard library makes checked exceptions a pain in the ass. One of the many reasons I am glad I switched to Scala for all new projects years ago.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 12:14 -0800 |
| Message-ID | <a909f01c-bfdd-4aa3-8527-931c855d617e@googlegroups.com> |
| In reply to | #33592 |
On Thursday, February 4, 2016 at 3:01:32 PM UTC-5, Silvio wrote: > On 02/04/2016 07:09 PM, Eric Douglas wrote: > > > > I mean the norm in Java as opposed to unchecked exceptions. > > > > Checked exceptions are better than unchecked ones, because if you have to trap for them regardless, the checked ones tell you what to look for. If everything is unchecked then every method you call from someone else's API that could possibly throw an error you have to remember to add a trap for to somehow avoid crashing your application. If it's going to throw an error that's going to bring my user to a halt it had better be something I consider critical and know no way around. > > > > That is the theory and it is not bad at all. Nobody says the decision to > try checked exceptions was made by stupid people and it was immediately > obvious that it was a bad idea. > > Checked exceptions are viral not unlike the GPL. Every higher level in > the call chain has to declare to throw the complete superset of all > exceptions thrown in its children unless someone does one of the "smart > moves" somewhere in there to hide exceptions in some way (throws > Exception, catch-log-absorb, wrap in RuntimeException or any other > misguided variant). > > The current consensus is that "fail fast and hard" is mostly better than > laborious attempts for partial repairs at various levels. Checked > exceptions promote the latter and make the former very hard. > > That with the fact that exceptions are highly overused in the standard > library makes checked exceptions a pain in the ass. One of the many > reasons I am glad I switched to Scala for all new projects years ago. Are you and the OP still running Windows 98? You sound like you enjoy bsod. I don't know Scala. Is there a forum for that? You guys should be posting your dislike for exceptions over there, not here, since you're making such a poor case. OP, you really shouldn't create a blog to troll a forum. Someone might stumble on it and think it's real.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-04 15:16 -0500 |
| Message-ID | <n90bej$a07$1@dont-email.me> |
| In reply to | #33592 |
On 2/4/2016 3:01 PM, Silvio wrote:
> [...]
> The current consensus is that "fail fast and hard" is mostly better than
> laborious attempts for partial repairs at various levels. Checked
> exceptions promote the latter and make the former very hard.
"Fail fast and hard" is a consensus? Since when?
Long years ago (before Java, even before C was well-known), I worked
on air traffic control systems. "Fail fast and hard" was not an option,
not nohow.
Today, people are developing software for the self-driving car you
may buy in a year or two. Would you encourage them to "Fail fast and
hard" while that car is carrying you along the Autobahn?
Perhaps Java is banned from nuclear plants not because of problems
with the language, but because it attracts people with ideas like yours.
> That with the fact that exceptions are highly overused in the standard
> library makes checked exceptions a pain in the ass. One of the many
> reasons I am glad I switched to Scala for all new projects years ago.
1) Agreed that some of the library classes use exceptions poorly.
2) If you've abandoned Java, why waste your time on this forum?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-04 21:37 +0100 |
| Message-ID | <56b3b67e$0$23868$e4fe514c@news.xs4all.nl> |
| In reply to | #33595 |
On 02/04/2016 09:16 PM, Eric Sosman wrote: > On 2/4/2016 3:01 PM, Silvio wrote: >> [...] >> The current consensus is that "fail fast and hard" is mostly better than >> laborious attempts for partial repairs at various levels. Checked >> exceptions promote the latter and make the former very hard. > > "Fail fast and hard" is a consensus? Since when? > > Long years ago (before Java, even before C was well-known), I worked > on air traffic control systems. "Fail fast and hard" was not an option, > not nohow. > > Today, people are developing software for the self-driving car you > may buy in a year or two. Would you encourage them to "Fail fast and > hard" while that car is carrying you along the Autobahn? > > Perhaps Java is banned from nuclear plants not because of problems > with the language, but because it attracts people with ideas like yours. > Exceptions where initially meant to handle, well, exceptional cases. Things like program bugs, configuration errors or unexpected hardware failure. ClassNotFoundException makes sense, FileNotFoundException is moronic. And I hope you know that fail fast does not mean that a total system should exit and print an error code. It means that it is best to have a failure somewhere deep inside a code branch promote fast and loud to a suitable high level where there is enough information to decide what to do. If a sensor in my self-driving car is broken I want it to stop instead of going faster and faster because you attempted to handle a BrokenSpedometerException by returning a harmless zero. >> That with the fact that exceptions are highly overused in the standard >> library makes checked exceptions a pain in the ass. One of the many >> reasons I am glad I switched to Scala for all new projects years ago. > > 1) Agreed that some of the library classes use exceptions poorly. > > 2) If you've abandoned Java, why waste your time on this forum? > Scala runs on the JVM and Scala code uses much of the Java standard library. It is not like Java has completely vanished from my world.
[toc] | [prev] | [next] | [standalone]
| From | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 13:08 -0800 |
| Message-ID | <7fc67802-c2c4-4020-87fb-652bf39bf95b@googlegroups.com> |
| In reply to | #33596 |
On Thursday, February 4, 2016 at 3:37:31 PM UTC-5, Silvio wrote: > Exceptions where initially meant to handle, well, exceptional cases. > Things like program bugs, configuration errors or unexpected hardware > failure. ClassNotFoundException makes sense, FileNotFoundException is > moronic. > You don't have to be exceptional to be an exception. If you have a round hole and 5,000 round pegs, then you come across one square peg that is an exception. FileNotFound is an exception if I'm passing in a known file name and the file is not there. Perhaps the file even got deleted from the time I got a directory listing to the time I attempted to read the file. Just because you assume your file may not be there doesn't mean everyone will. You may think everyone should assume walking on two legs is not exceptional for a human, but you will find it exceptional when you manage to walk after the doctor says you never will. > And I hope you know that fail fast does not mean that a total system > should exit and print an error code. It means that it is best to have a > failure somewhere deep inside a code branch promote fast and loud to a > suitable high level where there is enough information to decide what to do. > In what order do you write your Java? Exceptions at the deepest level should jump directly to the highest level that would "know what to do with them" skipping every level in between? Exceptions could happen at any level, and they most likely won't know how many levels there will be. If they don't pass through every level, how will the highest level know to look for them? > If a sensor in my self-driving car is broken I want it to stop instead > of going faster and faster because you attempted to handle a > BrokenSpedometerException by returning a harmless zero. > So, if BrokenSpedometerException, apply maximum break even if prior speed may have been 100. Good luck with that. I'd prefer it has multiple levels to pass the exception through. If my sensor fails so my car doesn't know how to stop because it suddenly has no idea how fast I'm going, is there a backup sensor? Is there a camera, some other way of calculating speed? I expect a lot of redundancy with self-driving vehicles so they don't start cluttering up the highways when components fail. > > >> That with the fact that exceptions are highly overused in the standard > >> library makes checked exceptions a pain in the ass. One of the many > >> reasons I am glad I switched to Scala for all new projects years ago. > > > > 1) Agreed that some of the library classes use exceptions poorly. > > > > 2) If you've abandoned Java, why waste your time on this forum? > > > > Scala runs on the JVM and Scala code uses much of the Java standard > library. It is not like Java has completely vanished from my world. One method being able to throw 6 different checked exceptions is not necessarily poor design. The only poor exception is one that tells me my method call failed with no indication why.
[toc] | [prev] | [next] | [standalone]
| From | 4ndre4 <4ndre4@4ndre4.com.invalid> |
|---|---|
| Date | 2016-02-04 21:16 +0000 |
| Message-ID | <n90euo$gpl$3@dont-email.me> |
| In reply to | #33599 |
On 04/02/2016 21:08, Eric Douglas wrote: [...] > You don't have to be exceptional to be an exception. I disagree on this. If exceptions become the rule, then something is wrong in the design. The outcome of a method should be predictable. Exceptions should not be predictable. A code like this: public void validateUser(User user) throws UserDoesNotExistException; is wrong, in my opinion. This one: public void grantWriteAccess(User user) throws UserDoesNotExistException; is probably correct. -- 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 | Eric Douglas <e.d.programmer@gmail.com> |
|---|---|
| Date | 2016-02-04 13:28 -0800 |
| Message-ID | <f37bd996-e2bb-4d86-b2e3-8fd8575e93f6@googlegroups.com> |
| In reply to | #33600 |
On Thursday, February 4, 2016 at 4:17:05 PM UTC-5, 4ndre4 wrote: > > You don't have to be exceptional to be an exception. > > I disagree on this. If exceptions become the rule, then something is > wrong in the design. The outcome of a method should be predictable. > Exceptions should not be predictable. A code like this: > > public void validateUser(User user) throws UserDoesNotExistException; > > is wrong, in my opinion. This one: > > public void grantWriteAccess(User user) throws UserDoesNotExistException; > > is probably correct. No one said anything about a rule. I said exceptions don't need to be exceptional, as in extraordinary. They just tend to be something unexpected. validateUser should not throw UserDoesNotExistException, that would be the boolean return value. The readFile(String filename) method throwing IOException may not seem logical since I expect it will be able to read the file if it didn't get the FileNotFoundException or the SecurityException, but maybe it was a big file, a slow connection, somehow the connection to the file got dropped in the middle which may only happen on the local network one in 100,000 times. It may not be extraordinary exceptional like your hard drive crashed. It may just work if you retry it, but you still want to be aware it could happen and trap for it so your application doesn't just stop working.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-04 23:11 +0000 |
| Message-ID | <n90lqs$dn5$1@dont-email.me> |
| In reply to | #33600 |
On Thu, 04 Feb 2016 21:16:49 +0000, 4ndre4 wrote: > On 04/02/2016 21:08, Eric Douglas wrote: > > [...] >> You don't have to be exceptional to be an exception. > > I disagree on this. If exceptions become the rule, then something is > wrong in the design. The outcome of a method should be predictable. > Exceptions should not be predictable. A code like this: > > public void validateUser(User user) throws UserDoesNotExistException; > > is wrong, in my opinion. This one: > There are pros and cons to the use of exceptions. I think you have to be reasonably familiar with languages that use exceptions (Java, PL/1) and those that do not (C, bash scripts, Algol, Pascal or COBOL) to see both sides of the issue. The benefit of using exceptions is that the exception stops the current loop or whatever and switches control to somewhere where it can be dealt with, so, for instance, in a read loop an End Of File exception is much cleaner to code for than, in the case where a function return code is an all-purpose result code, you'd have less tidy code because you have to (a) test every result to see whether its a successful read, end of file, or some error. Their disadvantage is if the exception trap is somewhere outside the main process execution path, it can force you to track where the exception occurred and jump through a hoop or two to restart after dealing with the exception. On the whole I prefer having exceptions, apart from in PL/1 where their use for some exceptions is just perverse, because in languages like C the logic needed to disentangle good results, expected events like end of file, and actual problems in order to deal with each group in the right way, can obscure the program structure unless its done very carefully. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | a.laforgia@gmail.com |
|---|---|
| Date | 2016-02-05 04:21 -0800 |
| Message-ID | <96897939-8987-4dcf-9d83-8bb48d30a429@googlegroups.com> |
| In reply to | #33605 |
On Thursday, 4 February 2016 23:14:24 UTC, Martin Gregorie wrote: [...] > There are pros and cons to the use of exceptions. Martin, no one is questioning the benefits of exceptions. They are known. What is being questioned is whether there should be *checked* exceptions or not. In my opinion, checked exceptions are a good thing as they represent alternative results for methods and force the user to consider all the potential outcomes. I think dividing them in "contingency" exceptions and "fault" exceptions, as Barry Ruzek suggests[*], is good to clarify how they should be designed and used. [*] http://www.oracle.com/technetwork/java/effective-exceptions-092345.html
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-05 13:07 +0000 |
| Message-ID | <n926r1$v4e$1@dont-email.me> |
| In reply to | #33612 |
On Fri, 05 Feb 2016 04:21:37 -0800, a.laforgia wrote: > In my opinion, checked exceptions are a good thing as > they represent alternative results for methods and force the user to > consider all the potential outcomes. I think dividing them in > "contingency" exceptions and "fault" exceptions, as Barry Ruzek > suggests[*], is good to clarify how they should be designed and used. > Yes, I agree, with that and I prefer that all exceptions where continuation is possible after the exception has been thrown should be checked, but of course the class designer must think carefully before deciding whether an exception should be checked or unchecked. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-04 18:04 -0500 |
| Message-ID | <n90l8f$kiu$1@dont-email.me> |
| In reply to | #33596 |
On 2/4/2016 3:37 PM, Silvio wrote:
> On 02/04/2016 09:16 PM, Eric Sosman wrote:
>> On 2/4/2016 3:01 PM, Silvio wrote:
>>> [...]
>>> The current consensus is that "fail fast and hard" is mostly better than
>>> laborious attempts for partial repairs at various levels. Checked
>>> exceptions promote the latter and make the former very hard.
>>
>> "Fail fast and hard" is a consensus? Since when?
>>
>> Long years ago (before Java, even before C was well-known), I worked
>> on air traffic control systems. "Fail fast and hard" was not an option,
>> not nohow.
>>
>> Today, people are developing software for the self-driving car you
>> may buy in a year or two. Would you encourage them to "Fail fast and
>> hard" while that car is carrying you along the Autobahn?
>>
>> Perhaps Java is banned from nuclear plants not because of problems
>> with the language, but because it attracts people with ideas like yours.
>>
>
> Exceptions where initially meant to handle, well, exceptional cases.
> Things like program bugs, configuration errors or unexpected hardware
> failure. ClassNotFoundException makes sense, FileNotFoundException is
> moronic.
Thank you for using rational argument instead of loaded terms.
"File not found" is surely a condition that can occur, and if it
occurs it certainly could cause the failure of an attempted operation
on the non-existent file. As such, the condition must be reported in
some fashion. The two I know of are to return a special value (maybe
null, maybe something like an Optional<Stream>) or to throw an exception
(checked or unchecked).
C takes the special value approach, and we've all seen how very
successful that's been in getting C programmers to check for failures!
Throwing an exception has several advantages -- the traceback alone is
an enormous benefit -- and throwing a checked exception prevents the
programmer from ignoring the possibility of failure. Admittedly, Java
cannot force the programmer to do a good job of dealing with failure;
the empty catch block is always possible, as is the catch block with
something silly inside. In my opinion (which, unlike the O.P., I do
not call "proof"), a programmer who is prompted to consider strange
outcomes will handle them better than someone allowed to ignore them.
I'll admit that exceptions are no cure-all. There's the annoying
problem of catching an exception, trying to clean up afterward, and
getting additional exceptions during the cleanup -- the whole business
of "suppressed exceptions" seems awkward at best. And there's always
room for debate about which exceptions (in which circumstances!) should
be checked and which unchecked; UncheckedIOException demonstrates that
there is no one hard-and-fast rule for resolving the question. Still,
"It is less than perfect" is no synonym for "it is BAD!"
> And I hope you know that fail fast does not mean that a total system
> should exit and print an error code. It means that it is best to have a
> failure somewhere deep inside a code branch promote fast and loud to a
> suitable high level where there is enough information to decide what to do.
... which is precisely what throwing an exception accomplishes. The
level that has "enough" knowledge can catch it and cope, while the less
well-informed layers can just pass it along.
> If a sensor in my self-driving car is broken I want it to stop instead
> of going faster and faster because you attempted to handle a
> BrokenSpedometerException by returning a harmless zero.
You're on the Autobahn at the average speed of 142 km/h (88 mph,
see Wikipedia for citation), and if you "fail fast and hard" it will
be your final failure. See that eighteen-wheeler behind you? It'll
soon be atop you.
Besides, who said anything about a "harmless zero?" I want the
car to detect the broken speedometer and then *do something* about it.
Ignoring it is no good, "fail hard and fast" is also no good. There
must be code to *cope* with the exceptional condition.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2016-02-05 11:40 -0800 |
| Message-ID | <bdu9bb55qi6clnekmui8nur9q0nfkbob6n@4ax.com> |
| In reply to | #33604 |
On Thu, 4 Feb 2016 18:04:12 -0500, Eric Sosman
<esosman@comcast-dot-net.invalid> wrote:
[snip]
> C takes the special value approach, and we've all seen how very
>successful that's been in getting C programmers to check for failures!
And we also see how successful exceptions have been in getting
Java programmers to check for failures.
In both cases, it is that some do and some do not.
>Throwing an exception has several advantages -- the traceback alone is
>an enormous benefit -- and throwing a checked exception prevents the
>programmer from ignoring the possibility of failure. Admittedly, Java
>cannot force the programmer to do a good job of dealing with failure;
>the empty catch block is always possible, as is the catch block with
>something silly inside. In my opinion (which, unlike the O.P., I do
>not call "proof"), a programmer who is prompted to consider strange
>outcomes will handle them better than someone allowed to ignore them.
In a uni course, we had to write a secure FTP program. We were
given the calls for a crypto package. Unfortunately, there were a
bunch of exceptions that could occur. All I could do is compile, not
the errors, add a handling for each to abort at that point, and sigh
about this time waste.
I much prefer to be able to catch errors in one spot unless I can
do anything with them.
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-04 23:22 +0100 |
| Message-ID | <n90ivr$tjq$1@news.albasani.net> |
| In reply to | #33592 |
Am 04.02.2016 17:57, schrieb Silvio:
>
> Adding a boolean flag to the compiler that would disable the check would
> probably be quite trivial...
You can trick the Java compiler even while that check is active. That is
you can in fact throw the checked exception without wrapping it in a
RuntimeException, e. g. with Lombok‘s @SneakyThrow annotation. Check it
out for a bit of fun.
Am 04.02.2016 21:01, schrieb Silvio:
> that exceptions are highly overused in the standard
> library makes checked exceptions a pain in the ass. One of the many
> reasons I am glad I switched to Scala for all new projects years ago.
I agree that checked exceptions are overused. Case in point: because a
checked exception thrown by a Java 8 lambda does not transparently
propagate to the surrounding code, any checked-exception-throwing
library code sooner or later really is going to be painful.
Example: Wouldn't it be nice if the following compiled?
void appendAll(Iterable<String> values, Appendable out)
{
values.forEach(s -> out.append(s));
}
But that doesn't mean checked exceptions are all bad. And as far as Java
is concerned, we're discussing a moot point, because they are certainly
here to stay.
What I'd really be interested in is to hear how people programming in
other (JVM) languages that do not have checked exceptions (which is most
languages) nowadays avoid the nightmare that I experienced many years
ago programming in C++. There usually wasn't any information or
documentation on what exceptions some library code might throw, so
whenever a new one popped up - which of course always happened in
production - you had to adapt your code to deal with it. I didn't like
that very much either, on account of those long sleepless nights.
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | ruben <ceo@iran.gov> |
|---|---|
| Date | 2016-02-15 11:45 +0000 |
| Message-ID | <n9sdpj$cej$5@reader1.panix.com> |
| In reply to | #33592 |
On Thu, 04 Feb 2016 21:01:22 +0100, Silvio wrote: > Checked exceptions are viral not unlike the GPL. Every higher level in > the call chain has to declare to throw the complete superset of all ahh the wonders of usenet. I thought we outgrew this stage of development, but maybe not.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-04 11:57 -0800 |
| Message-ID | <bff8c74e-3c2c-469e-ac9a-e805ceecb586@googlegroups.com> |
| In reply to | #33582 |
On Thursday, 4 February 2016 11:57:16 UTC-5, Silvio wrote: > On 02/04/2016 05:15 PM, Eric Douglas wrote: > > On Thursday, February 4, 2016 at 10:19:27 AM 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). > > > > 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. > > > > I suppose you mean "the norm" in its limited meaning being "the norm in > Java"? Note that Java is the only language that has checked exceptions. > > You make a case for exceptions in general and not for checked ones in > particular. Unchecked exceptions can of course be caught based on their > exact or generic type just like checked ones. In fact, checked > exceptions only exist in the reasoning of the standard Java compiler. > Everything else about exceptions is handled runtime. The JVM could not > care less what exceptions a method might throw. > > Adding a boolean flag to the compiler that would disable the check would > probably be quite trivial... > > Scala has ditched checked exceptions in favor of unchecked ones. And > that language has been designed by the man who wrote the GJ compiler > that formed the basis of the standard Java 1.3 compiler even before > generics became part of the language. He had the hindsight advantage. > Other languages that where developed after Java also chose to take the > unchecked route. For good reasons. > > Most proponents I have met use mainly Java and are just used to doing it > the checked way. and the checked way is the bad way.
[toc] | [prev] | [next] | [standalone]
| From | Silvio <silvio@internet.com> |
|---|---|
| Date | 2016-02-04 21:07 +0100 |
| Message-ID | <56b3af69$0$23796$e4fe514c@news.xs4all.nl> |
| In reply to | #33591 |
On 02/04/2016 08:57 PM, boxzou@gmail.com wrote: > On Thursday, 4 February 2016 11:57:16 UTC-5, Silvio wrote: >> On 02/04/2016 05:15 PM, Eric Douglas wrote: >>> On Thursday, February 4, 2016 at 10:19:27 AM 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). >>> >>> 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. >>> >> >> I suppose you mean "the norm" in its limited meaning being "the norm in >> Java"? Note that Java is the only language that has checked exceptions. >> >> You make a case for exceptions in general and not for checked ones in >> particular. Unchecked exceptions can of course be caught based on their >> exact or generic type just like checked ones. In fact, checked >> exceptions only exist in the reasoning of the standard Java compiler. >> Everything else about exceptions is handled runtime. The JVM could not >> care less what exceptions a method might throw. >> >> Adding a boolean flag to the compiler that would disable the check would >> probably be quite trivial... >> >> Scala has ditched checked exceptions in favor of unchecked ones. And >> that language has been designed by the man who wrote the GJ compiler >> that formed the basis of the standard Java 1.3 compiler even before >> generics became part of the language. He had the hindsight advantage. >> Other languages that where developed after Java also chose to take the >> unchecked route. For good reasons. >> >> Most proponents I have met use mainly Java and are just used to doing it >> the checked way. > > and the checked way is the bad way. > There is no bad in there. Unless we would be talking about your theoretical proof. That was unconvincing at best.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web