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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Sebastian <news@seyweiler.dyndns.org> |
|---|---|
| Date | 2016-02-07 14:49 +0100 |
| Message-ID | <n97i1i$6f3$1@news.albasani.net> |
| In reply to | #33625 |
Am 06.02.2016 15:23, schrieb Silvio: > 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. I did a similar thing, where we had service modules that were wired together at runtime using customizable communication protocols (RMI, JMS, WS). We'd throw either TechnicalException or BusinessException from the service interfaces, which I guess would roughly correspond to your fatal and non-fatal categories, and which had to be checked exceptions because the framework required it. And boy did I hate the method signature pollution handing up these exceptions from low-level methods to each module's top-level exception handler. I guess there are many similarly stupid uses of checked exceptions, which gives them a bad name generally. Several people have remarked how useful checked exceptions can be when you are in a situation where you must sensibly deal with exceptional cases and therefore have a need to know what exceptions might arise. None of the checked-exceptions-are-bad posts in this discussion have really addressed that point. When there are only RuntimeExceptions, do you all play whac-a-mole? -- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2016-02-07 21:55 +0100 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <dhppanFsdrtU1@mid.individual.net> |
| In reply to | #33641 |
On 07.02.2016 15:09, Stefan Ram wrote: > Some methods can't know all their exceptions at > documentation time because they call other methods that > are only determined at runtime. But this is also the case > where checked exceptions are difficult to use. How should that be possible? Can you show an example where not all checked exceptions can be determined at documentation time (i.e. after successful compiling)? Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:39 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <25c9bda0-2d07-4339-a7cd-2b868584117d@googlegroups.com> |
| In reply to | #33645 |
On Sunday, 7 February 2016 15:56:15 UTC-5, Robert Klemme wrote: > On 07.02.2016 15:09, Stefan Ram wrote: > > > Some methods can't know all their exceptions at > > documentation time because they call other methods that > > are only determined at runtime. But this is also the case > > where checked exceptions are difficult to use. > > How should that be possible? Can you show an example where not all > checked exceptions can be determined at documentation time (i.e. after > successful compiling)? > > Kind regards > > robert > > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ under JPA, you can plug in Oracle DB, Derby DB, IBM DB2. Each db throws different kinds of exception although they are all subclasses of SQLException. Theoretically you can also plug in Google big table which does not throw SQLException at all, or some other things. There is no way JPA API can document all these exceptions!
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2016-02-08 13:30 +0100 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <dhrg2nFakleU1@mid.individual.net> |
| In reply to | #33652 |
On 07.02.2016 23:39, boxzou@gmail.com wrote: > On Sunday, 7 February 2016 15:56:15 UTC-5, Robert Klemme wrote: >> On 07.02.2016 15:09, Stefan Ram wrote: >> >>> Some methods can't know all their exceptions at >>> documentation time because they call other methods that >>> are only determined at runtime. But this is also the case >>> where checked exceptions are difficult to use. >> >> How should that be possible? Can you show an example where not all >> checked exceptions can be determined at documentation time (i.e. after >> successful compiling)? > under JPA, you can plug in Oracle DB, Derby DB, IBM DB2. Each db > throws different kinds of exception although they are all subclasses > of SQLException. Theoretically you can also plug in Google big table > which does not throw SQLException at all, or some other things. > There is no way JPA API can document all these exceptions! Well, the API documents SQLException so from a caller's perspective he knows what to catch - and there won't be any exception thrown that could escape that catch. If anything I'd rather argue that the design of JDBC has the flaw to not distinguish basic classes of errors that can surface and declare them as checked exceptions, for example: - syntax errors in SQL executed (this could even be considered a runtime exception because it is a coding error of some sort) - communication issues with a remote database server - constraint violations - resource issues, e.g. database server cancels an SQL statement because it uses too many resources (time, memory, IO) And you use JPA to abstract the concrete database model used so it would be very unwise to start writing catch clauses for all sorts of database specific exceptions (apart from the fact that this is often not possible because you add JDBC drivers at deployment time so the compiler does not see them). So it is practically not possible (even with unchecked exceptions!) and it is not wise from a modularity point of view. And it is not needed since you usually get all the details of nested exceptions in an application's log. robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 06:14 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <1eb89683-ed9b-4b03-b846-8e24c9f87a4a@googlegroups.com> |
| In reply to | #33669 |
On Monday, 8 February 2016 07:30:37 UTC-5, Robert Klemme wrote: > On 07.02.2016 23:39, b...@gmail.com wrote: > > On Sunday, 7 February 2016 15:56:15 UTC-5, Robert Klemme wrote: > >> On 07.02.2016 15:09, Stefan Ram wrote: > >> > >>> Some methods can't know all their exceptions at > >>> documentation time because they call other methods that > >>> are only determined at runtime. But this is also the case > >>> where checked exceptions are difficult to use. > >> > >> How should that be possible? Can you show an example where not all > >> checked exceptions can be determined at documentation time (i.e. after > >> successful compiling)? > > > under JPA, you can plug in Oracle DB, Derby DB, IBM DB2. Each db > > throws different kinds of exception although they are all subclasses > > of SQLException. Theoretically you can also plug in Google big table > > which does not throw SQLException at all, or some other things. > > There is no way JPA API can document all these exceptions! > > Well, the API documents SQLException so from a caller's perspective he > knows what to catch - and there won't be any exception thrown that could > escape that catch. If anything I'd rather argue that the design of JDBC > has the flaw to not distinguish basic classes of errors that can surface > and declare them as checked exceptions, for example: > - syntax errors in SQL executed (this could even be considered a > runtime exception because it is a coding error of some sort) > - communication issues with a remote database server > - constraint violations > - resource issues, e.g. database server cancels an SQL statement > because it uses too many resources (time, memory, IO) > > And you use JPA to abstract the concrete database model used so it would > be very unwise to start writing catch clauses for all sorts of database > specific exceptions (apart from the fact that this is often not possible > because you add JDBC drivers at deployment time so the compiler does not > see them). So it is practically not possible (even with unchecked > exceptions!) and it is not wise from a modularity point of view. And it > is not needed since you usually get all the details of nested exceptions > in an application's log. > > robert > > -- > remember.guy do |as, often| as.you_can - without end > http://blog.rubybestpractices.com/ JPA does not throw SQLException. It does not assume it will only deal with relational database.
[toc] | [prev] | [next] | [standalone]
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Date | 2016-02-08 20:55 +0100 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <dhsa4sFhj5qU1@mid.individual.net> |
| In reply to | #33677 |
On 08.02.2016 15:14, boxzou@gmail.com wrote: > On Monday, 8 February 2016 07:30:37 UTC-5, Robert Klemme wrote: >> And you use JPA to abstract the concrete database model used so it would >> be very unwise to start writing catch clauses for all sorts of database >> specific exceptions (apart from the fact that this is often not possible >> because you add JDBC drivers at deployment time so the compiler does not >> see them). So it is practically not possible (even with unchecked >> exceptions!) and it is not wise from a modularity point of view. And it >> is not needed since you usually get all the details of nested exceptions >> in an application's log. > JPA does not throw SQLException. It does not assume it will only deal with relational database. Right, yes. Thank you for correction! The point is still that, whatever a library / module throws, as a user of that module you would not want to catch detailed exceptions of underlying layers of software. robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-02-08 16:06 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <de650413-5f85-4a4e-954d-ae83b3576f12@googlegroups.com> |
| In reply to | #33677 |
On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com wrote: > JPA does not throw SQLException. It does not assume it will only deal with relational database. JPA is not a SQL library, so why would it even remotely merit throwing 'SQLException' in the first place? -- Lew
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-08 18:38 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <cf281e75-60b9-461a-b197-c61296219599@googlegroups.com> |
| In reply to | #33696 |
On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: > On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com wrote: > > JPA does not throw SQLException. It does not assume it will only deal with relational database. > > JPA is not a SQL library, so why would it even remotely merit throwing 'SQLException' in the first place? > but it is calling JDBC, which throws SQLException. So what should JPA do with the SQLException?
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-09 12:15 +0000 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <n9cl9l$qgl$1@dont-email.me> |
| In reply to | #33702 |
On Mon, 08 Feb 2016 18:38:59 -0800, boxzou wrote: > On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: >> On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com >> wrote: >> > JPA does not throw SQLException. It does not assume it will only >> > deal with relational database. >> >> JPA is not a SQL library, so why would it even remotely merit throwing >> 'SQLException' in the first place? >> > but it is calling JDBC, which throws SQLException. So what should JPA > do with the SQLException? Catch it and deal with the problem its signalling. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-09 04:59 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <3914968d-64e6-4320-9726-85c360563cfb@googlegroups.com> |
| In reply to | #33710 |
On Tuesday, 9 February 2016 07:19:05 UTC-5, Martin Gregorie wrote: > On Mon, 08 Feb 2016 18:38:59 -0800, boxzou wrote: > > > On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: > >> On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com > >> wrote: > >> > JPA does not throw SQLException. It does not assume it will only > >> > deal with relational database. > >> > >> JPA is not a SQL library, so why would it even remotely merit throwing > >> 'SQLException' in the first place? > >> > > but it is calling JDBC, which throws SQLException. So what should JPA > > do with the SQLException? > > Catch it and deal with the problem its signalling. > I don't follow you. Could you elaborate?
[toc] | [prev] | [next] | [standalone]
| From | Lew <lewbloch@gmail.com> |
|---|---|
| Date | 2016-02-10 12:13 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <b895a4d1-d0bc-4efe-a97c-72f729c381b0@googlegroups.com> |
| In reply to | #33702 |
On Monday, February 8, 2016 at 6:39:07 PM UTC-8, box...@gmail.com wrote: > On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: > > On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com wrote: > > > JPA does not throw SQLException. It does not assume it will only deal with relational database. > > > > JPA is not a SQL library, so why would it even remotely merit throwing 'SQLException' in the first place? > > > but it is calling JDBC, which throws SQLException. So what should JPA do with the SQLException? What *does* JPA doe with 'SQLException'? I see nothing in, say, the Javadocs for EclipseLink that even mention 'SQLException'. Probably because it is not an object-oriented notion, and thus inappropriate for JPA to expose, I'm thinking. And remember, JPA can connect to sources that don't have 'SQLException' in their access API. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-10 19:00 -0800 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <8e9abf09-e0de-4e0a-a45a-627c37a2525d@googlegroups.com> |
| In reply to | #33753 |
On Wednesday, 10 February 2016 15:13:40 UTC-5, Lew wrote: > On Monday, February 8, 2016 at 6:39:07 PM UTC-8, box...@gmail.com wrote: > > On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: > > > On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com wrote: > > > > JPA does not throw SQLException. It does not assume it will only deal with relational database. > > > > > > JPA is not a SQL library, so why would it even remotely merit throwing 'SQLException' in the first place? > > > > > but it is calling JDBC, which throws SQLException. So what should JPA do with the SQLException? > > What *does* JPA doe with 'SQLException'? I see nothing in, say, the Javadocs for EclipseLink that even mention 'SQLException'. Probably because it is not an object-oriented notion, and thus inappropriate for JPA to expose, I'm thinking. > > And remember, JPA can connect to sources that don't have 'SQLException' in their access API. > that's right. JPA should be concerned with SQLException. If SQLException were a runtime exception, that would be easy, JPA does not need to anything, just let it pass through. But because SQLException is a checked exception, JPA dedicated a lot of code to catch and wrap it.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-11 12:18 +0000 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <n9hu76$o9e$1@dont-email.me> |
| In reply to | #33764 |
On Wed, 10 Feb 2016 19:00:47 -0800, boxzou wrote: > On Wednesday, 10 February 2016 15:13:40 UTC-5, Lew wrote: >> On Monday, February 8, 2016 at 6:39:07 PM UTC-8, box...@gmail.com >> wrote: >> > On Monday, 8 February 2016 19:06:12 UTC-5, Lew wrote: >> > > On Monday, February 8, 2016 at 6:14:24 AM UTC-8, box...@gmail.com >> > > wrote: >> > > > JPA does not throw SQLException. It does not assume it will only >> > > > deal with relational database. >> > > >> > > JPA is not a SQL library, so why would it even remotely merit >> > > throwing 'SQLException' in the first place? >> > > >> > but it is calling JDBC, which throws SQLException. So what should >> > JPA do with the SQLException? >> >> What *does* JPA doe with 'SQLException'? I see nothing in, say, the >> Javadocs for EclipseLink that even mention 'SQLException'. Probably >> because it is not an object-oriented notion, and thus inappropriate for >> JPA to expose, I'm thinking. >> >> And remember, JPA can connect to sources that don't have 'SQLException' >> in their access API. >> > that's right. JPA should be concerned with SQLException. If > SQLException were a runtime exception, that would be easy, JPA does not > need to anything, just let it pass through. But because SQLException is > a checked exception, JPA dedicated a lot of code to catch and wrap it. JPA almost certainly needs to deal with SQLExceptions regardless of whether they are checked or not. Remember that, as you said, JPA can deal with non-SQL data sources. So, it follows that it *must* catch SQLExceptions, along with those thrown by any other data store it supports, to prevent them from being seen by JPA's callers which, by JPA's design neither know nor care what data store is being used. This in turn means that any SQLExceptions that can't be properly handled by JPA will be replaced by JPA exceptions and rethrown. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | leif.roar@dimnakorr.com |
|---|---|
| Date | 2016-02-11 04:43 -0600 |
| Subject | Re: Java Checked Exceptions |
| Message-ID | <TMqdnU5Q2sBb-CHLnZ2dnUU78Q-dnZ2d@giganews.com> |
| In reply to | #33753 |
Lew <lewbloch@gmail.com> wrote: > > What *does* JPA doe with 'SQLException'? I see nothing in, > say, the Javadocs for EclipseLink that even mention 'SQLException'. > Probably because it is not an object-oriented notion, and thus > inappropriate for JPA to expose, I'm thinking. It translates it into its own set of exceptions (springing from PersistenceException, which inherits from RuntimeException) which have appropriate semantic meaning to the client. I suppose the reason why they've choosen to use unchecked exceptions is that a common use-case for JPA is where it's called indirectly through an IoC framework of some stripe. -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:34 -0800 |
| Message-ID | <95babb3c-78dc-45e0-ab21-92e76723b0c5@googlegroups.com> |
| In reply to | #33641 |
On Sunday, 7 February 2016 08:49:55 UTC-5, Sebastian wrote: > Am 06.02.2016 15:23, schrieb Silvio: > > 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. > > I did a similar thing, where we had service modules that were wired > together at runtime using customizable communication protocols (RMI, > JMS, WS). We'd throw either TechnicalException or BusinessException from > the service interfaces, which I guess would roughly correspond to your > fatal and non-fatal categories, and which had to be checked exceptions > because the framework required it. And boy did I hate the method > signature pollution handing up these exceptions from low-level methods > to each module's top-level exception handler. I guess there are many > similarly stupid uses of checked exceptions, which gives them a bad > name generally. > > Several people have remarked how useful checked exceptions can be when > you are in a situation where you must sensibly deal with exceptional > cases and therefore have a need to know what exceptions might arise. > None of the checked-exceptions-are-bad posts in this discussion have > really addressed that point. When there are only RuntimeExceptions, do > you all play whac-a-mole? > > -- Sebastian thanks for sharing your grief. Regarding whac-a-mole, no, we don't whac-a-mole. For example when we call JPA EntityManager.persist(someObject) to save an object into database triggering a constraint violation because the object is already in db, our code will catch that exception (we sometimes need to experiment to figure out what exception to catch because the original SQLException is wrapped and wrapped). Our code can't handle every exception, we have to pick which one we can handle and the rest can only be logged and reported (usually application server will do that for you). Checked exception is only useful in very shallow call stack which means very small project. But with small project, it is also easy to use unchecked exception or just some error codes.
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 14:11 -0800 |
| Message-ID | <b2a83914-d92a-4401-9934-2554b5226adc@googlegroups.com> |
| In reply to | #33625 |
On Saturday, 6 February 2016 09:23:18 UTC-5, Silvio wrote: > 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. exactly because the limitation of checked exception, you have to do things like that to keep things manageable. So your approach is not bad. But it is better if you just wrap all checked exceptions in runtime exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2016-02-07 23:19 +0000 |
| Message-ID | <n98jeh$rpt$1@dont-email.me> |
| In reply to | #33647 |
On Sun, 07 Feb 2016 14:11:08 -0800, boxzou wrote: > But it is better if you just wrap all checked exceptions in > runtime exceptions. > Certainly NOT! By suppressing the need to list exceptions thrown you've just removed the ability of javadocs to automatically document the exceptions that you expect the class's caller to catch. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | boxzou@gmail.com |
|---|---|
| Date | 2016-02-07 15:42 -0800 |
| Message-ID | <f12fa8cd-cad2-401d-b279-e65d67d141a0@googlegroups.com> |
| In reply to | #33653 |
On Sunday, 7 February 2016 18:22:49 UTC-5, Martin Gregorie wrote: > On Sun, 07 Feb 2016 14:11:08 -0800, boxzou wrote: > > > But it is better if you just wrap all checked exceptions in > > runtime exceptions. > > > Certainly NOT! > > By suppressing the need to list exceptions thrown you've just removed the > ability of javadocs to automatically document the exceptions that you > expect the class's caller to catch. > > > -- > martin@ | Martin Gregorie > gregorie. | Essex, UK > org | the point is Checked Exception is bad. There is no way you can automatically document the exceptions in a complex system.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2016-02-06 09:43 -0500 |
| Message-ID | <n950m6$ad9$1@dont-email.me> |
| In reply to | #33624 |
On 2/6/2016 9:13 AM, 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?
"Good or bad?" Meh. You pays your money and you takes your choice.
Wrapping a multitude of causes into a few exception types has the
advantage of parsimony, but may impose a greater burden on the caller
who needs more detailed information. Instead of writing separate catch
blocks for NoGoodException and FubarException and ThisSucksException,
he has to catch SomethingWentWrongException, use getCause(), and hope he
finds something recognizable.
On the other hand, if all he's going to do is clean up and rethrow,
SomethingWentWrongException may be all the precision he needs.
I'll also note that multi-catch
try {
...
} catch (ThisException | ThatException | TotherException ex) {
...
}
can be an effective clutter-reducer. And, of course, there's always
the strategy of
class SomethingWentWrongException extends Exception {...}
class NoGoodException extends SomethingWentWrongException {...}
class FubarException extends SomethingWentWrongException {...}
class ThisSucksException extends FubarException {...}
(when applicable).
There are, of course, places where the entire exception mechanism --
checked or not -- becomes awkward. Somebody's already mentioned how
poorly stream operations interact with exceptions; I guess the problem
of catching a whole cascade of exceptions thrown by different pipeline
stages in an asynchronous parallel stream is sort of, er, daunting. And
I'll admit that checked exceptions cause problems of their own in some
situations: Every time I'm forced to wrap a checked exception in a
RuntimeException just because some interface's method doesn't have a
throws clause, I feel slightly dirty. But IMO (not "proof"), checked
exceptions offer a useful prompt to coders, a reminder not to ignore
the corner cases.
--
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-07 14:14 -0800 |
| Message-ID | <fc7c1eb5-903b-4774-ab49-a11d214575c7@googlegroups.com> |
| In reply to | #33627 |
On Saturday, 6 February 2016 09:44:12 UTC-5, Eric Sosman wrote:
> On 2/6/2016 9:13 AM, 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?
>
> "Good or bad?" Meh. You pays your money and you takes your choice.
>
> Wrapping a multitude of causes into a few exception types has the
> advantage of parsimony, but may impose a greater burden on the caller
> who needs more detailed information. Instead of writing separate catch
> blocks for NoGoodException and FubarException and ThisSucksException,
> he has to catch SomethingWentWrongException, use getCause(), and hope he
> finds something recognizable.
>
> On the other hand, if all he's going to do is clean up and rethrow,
> SomethingWentWrongException may be all the precision he needs.
>
> I'll also note that multi-catch
>
> try {
> ...
> } catch (ThisException | ThatException | TotherException ex) {
> ...
> }
>
> can be an effective clutter-reducer. And, of course, there's always
> the strategy of
>
> class SomethingWentWrongException extends Exception {...}
>
> class NoGoodException extends SomethingWentWrongException {...}
>
> class FubarException extends SomethingWentWrongException {...}
>
> class ThisSucksException extends FubarException {...}
>
> (when applicable).
>
> There are, of course, places where the entire exception mechanism --
> checked or not -- becomes awkward. Somebody's already mentioned how
> poorly stream operations interact with exceptions; I guess the problem
> of catching a whole cascade of exceptions thrown by different pipeline
> stages in an asynchronous parallel stream is sort of, er, daunting. And
> I'll admit that checked exceptions cause problems of their own in some
> situations: Every time I'm forced to wrap a checked exception in a
> RuntimeException just because some interface's method doesn't have a
> throws clause, I feel slightly dirty. But IMO (not "proof"), checked
> exceptions offer a useful prompt to coders, a reminder not to ignore
> the corner cases.
>
> --
> esosman@comcast-dot-net.invalid
> "Don't be afraid of work. Make work afraid of you." -- TLM
good you see problem with checked exception with pipelines. Actually check exception is problematic in any framework because like pipelines frameworks uses lots of callback (or function classes).
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web