Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #30182 > unrolled thread

redesign exception

Back to article view | Back to comp.lang.java.programmer

Contents

  redesign exception boxzou@gmail.com - 2014-10-25 19:16 -0700
    Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 08:09 +0100
      Re: redesign exception rossum <rossum48@coldmail.com> - 2014-10-26 09:15 +0000
        Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 10:36 +0100
        Re: redesign exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-26 09:23 -0400
          Re: redesign exception boxzou@gmail.com - 2014-10-26 12:56 -0700
            Re: redesign exception Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-26 18:10 -0400
              Re: redesign exception boxzou@gmail.com - 2014-10-26 17:39 -0700
        Re: redesign exception boxzou@gmail.com - 2014-10-26 12:06 -0700
          Re: redesign exception Joerg Meier <joergmmeier@arcor.de> - 2014-10-26 20:41 +0100
      Re: redesign exception boxzou@gmail.com - 2014-10-26 12:46 -0700
        Re: redesign exception boxzou@gmail.com - 2014-10-26 13:12 -0700
        Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-26 16:50 -0500
          Re: redesign exception boxzou@gmail.com - 2014-10-26 17:21 -0700
        Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-27 01:05 +0000
          Re: redesign exception boxzou@gmail.com - 2014-10-26 19:38 -0700
            Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 00:13 -0500
              Re: redesign exception boxzou@gmail.com - 2014-10-27 04:59 -0700
              Re: redesign exception Marketa Jadalova <m-jadalova3@gmail.com> - 2014-10-27 16:55 +0000
                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 12:46 -0500
                  Re: redesign exception boxzou@gmail.com - 2014-10-27 15:48 -0700
                    Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-27 22:16 -0500
                  Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-27 23:54 +0100
                    Re: redesign exception boxzou@gmail.com - 2014-10-27 17:20 -0700
                    Re: redesign exception boxzou@gmail.com - 2014-10-28 07:12 -0700
                      Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-29 08:34 +0100
                        Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 11:17 +0000
                          Re: redesign exception Silvio <silvio@internet.com> - 2014-10-29 15:33 +0100
                            Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 11:35 -0500
                              Re: redesign exception boxzou@gmail.com - 2014-10-29 17:51 -0700
                                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 20:45 -0500
                                  Re: redesign exception boxzou@gmail.com - 2014-10-30 04:12 -0700
                                  Re: redesign exception Silvio <silvio@internet.com> - 2014-10-30 12:38 +0100
                                    Re: redesign exception boxzou@gmail.com - 2014-10-30 06:23 -0700
                            Re: redesign exception boxzou@gmail.com - 2014-10-29 17:01 -0700
                          Re: redesign exception Marketa Jadalova <m-jadalova3@gmail.com> - 2014-10-29 16:55 +0000
                            Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 17:29 +0000
                              Re: redesign exception Robert Klemme <shortcutter@googlemail.com> - 2014-10-29 18:59 +0100
                                Re: redesign exception Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 22:05 +0000
                              Re: redesign exception boxzou@gmail.com - 2014-10-29 18:04 -0700
                                Re: redesign exception Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2014-10-29 20:56 -0500
                                  Re: redesign exception boxzou@gmail.com - 2014-10-30 04:19 -0700
                                    Re: redesign exception boxzou@gmail.com - 2014-10-30 04:27 -0700
                                      Re: redesign exception boxzou@gmail.com - 2014-10-30 04:35 -0700
                            Re: redesign exception boxzou@gmail.com - 2014-10-29 18:01 -0700
                          Re: redesign exception boxzou@gmail.com - 2014-10-29 17:00 -0700
                        Re: redesign exception boxzou@gmail.com - 2014-10-29 16:56 -0700
      Re: redesign exception boxzou@gmail.com - 2014-10-26 12:52 -0700
    Re: redesign exception Silvio <silvio@internet.com> - 2014-10-27 09:03 +0100
      Re: redesign exception boxzou@gmail.com - 2014-10-27 05:06 -0700
        Re: redesign exception Silvio <silvio@internet.com> - 2014-10-27 13:32 +0100
          Re: redesign exception boxzou@gmail.com - 2014-10-27 07:01 -0700

Page 1 of 3  [1] 2 3  Next page →

#30182 — redesign exception

I think Java exception need an overhaul.  Here is why:

1. exception handling need very specific information (like primary key constraint violation).  For human, a detailed message is required, for software a code is required.

2. this code information currently is implemented partly as exception type.  But that is not enough, so some projects augment it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).

3. As there are so many exception codes (refer to the EclipseLink above), they can't be implemented using exception types in a scalable manner.  And they don't need to.  Essentially we are treating Exception types (conceptually some strings too) as codes.  So let's go back to just exception codes (strings).

4. If necessary, we can organize code into hierarchy: e.g. ReflectiveOperationException.NoSuchMethodFoundException.  So you can either catch the more specific code NoSuchMethodFoundException or a broader code ReflectiveOperationException.  This simulates catching super class exception.

5. With codes, it's much easier to define: for example, JreFaultCodes (https://github.com/pahakia/lib/blob/master/fault/src/main/java/pahakia/fault/JreFaultCodes.java) lists all about 850 Exceptions/Errors in JRE.

6. So I propose only one exception type: Fault.  And one exception code type: FaultCode.

6. The new catch syntax would be: catch(someExceptionCode, Fault fault).

For more details, please read my blog: http://tri-katch.blogspot.ca

[toc] | [next] | [standalone]

#30183

On Sat, 25 Oct 2014 19:16:53 -0700 (PDT), boxzou@gmail.com wrote:

> 1. exception handling need very specific information (like
> primary key constraint violation).  For human, a detailed message
> is required, for software a code is required.

I'm not sure what you are trying to say here. It seems like you are
describing Exceptions as they are now.

> 2. this code information currently is implemented partly as
> exception type.  But that is not enough, so some projects augment
> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).

That link leads to a dead/empty page.

> 3. As there are so many exception codes (refer to the EclipseLink
> above), they can't be implemented using exception types in a
> scalable manner.  And they don't need to.  Essentially we are
> treating Exception types (conceptually some strings too) as codes.
> So let's go back to just exception codes (strings).

Here I am again confused as to what you are trying to say. How are
Exceptions the way they are now not scaleable ? Have you personally ever
run into, or even know about any project that has scaling issues because it
has too many Exception types ?

Exceptions as Strings would be bad, because we would lose the ability for
compile time checking about the right Exceptions being caught/thrown.
Luckily, your later examples don't actually go back to Strings, but to
custom variables instead. I'm not sure whether these would be solid enough
for compile time validation.

> 4. If necessary, we can organize code into hierarchy: e.g.
> ReflectiveOperationException.NoSuchMethodFoundException.  So you can
> either catch the more specific code NoSuchMethodFoundException or a
> broader code ReflectiveOperationException.  This simulates catching super
> class exception.

Why add custom code to do something we already can do ?

> 5. With codes, it's much easier to define: for example, JreFaultCodes
> (https://github.com/pahakia/lib/blob/master/fault/src/main/java/pahakia/fault/JreFaultCodes.java)
> lists all about 850 Exceptions/Errors in JRE.

Personally, I find that monster class pretty unreadable. It violates Java
code conventions and throws everything into one pile, discarding the nice
hierarchical organization it had before.

> 6. So I propose only one exception type: Fault.  And one exception code type: FaultCode.

> 6. The new catch syntax would be: catch(someExceptionCode, Fault fault).

> For more details, please read my blog: http://tri-katch.blogspot.ca

I'm at a loss as to why you made this suggestion. Surely, you don't expect
Oracle to destroy any backwards compibility in a totally unprecedented
upheaval to fix ... the lack of scalability of having thousands of
Exceptions ?

I don't even see what the advantage of your suggestion would be. Classes
are not memory hungry monsters, they aren't horribly slow, they don't have
an addition fault line with typos in a String, they aren't a giant resource
hog, and they are even less typing than your suggestion:

public static final FaultCode UnsupportedClassVersionError_java_lang = new
FaultCode("java.lang.UnsupportodClassVersionError", 1, "{0}");

as opposed to

public class UnsupportedClassVersionError extends Exception {}

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30184

On Sun, 26 Oct 2014 08:09:10 +0100, Joerg Meier <joergmmeier@arcor.de>
wrote:

>> 2. this code information currently is implemented partly as
>> exception type.  But that is not enough, so some projects augment
>> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
>
>That link leads to a dead/empty page.
You need to include the final "(ELUG)" in the URL, then it works.

rossum

[toc] | [prev] | [next] | [standalone]

#30185

On Sun, 26 Oct 2014 09:15:19 +0000, rossum wrote:

> On Sun, 26 Oct 2014 08:09:10 +0100, Joerg Meier <joergmmeier@arcor.de>
> wrote:
>>> 2. this code information currently is implemented partly as
>>> exception type.  But that is not enough, so some projects augment
>>> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
>>That link leads to a dead/empty page.
> You need to include the final "(ELUG)" in the URL, then it works.

My browser history shows that I tried with "(ELUG" and "(ELUG))" this
morning - that's what I get for posting before coffee intake ;)

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30186

On 10/26/2014 5:15 AM, rossum wrote:
> On Sun, 26 Oct 2014 08:09:10 +0100, Joerg Meier <joergmmeier@arcor.de>
> wrote:
>
>>> 2. this code information currently is implemented partly as
>>> exception type.  But that is not enough, so some projects augment
>>> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
>>
>> That link leads to a dead/empty page.
> You need to include the final "(ELUG)" in the URL, then it works.

     ITYM you need to *remove* the final ")" from the original link.

     But IMHO the O.P. is just trying to generate hit counts for his
blog, and/or troll.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30191

@Eric,

I don't care about hit counts.  But I do want to draw the attention of Java developers to the deficiency of Java exceptions. 

>      But IMHO the O.P. is just trying to generate hit counts for his
> blog, and/or troll.

[toc] | [prev] | [next] | [standalone]

#30194

On 10/26/2014 3:56 PM, boxzou@gmail.com wrote:
> @Eric,
>
> I don't care about hit counts.  But I do want to draw the attention of Java developers to the deficiency of Java exceptions.
>
>>       But IMHO the O.P. is just trying to generate hit counts for his
>> blog, and/or troll.

     I'm sorry if I have wronged you.  However, no one with any sense of
what is practical would imagine that Java could be changed in such a
fundamental way: Such a change would invalidate all or very nearly all
the existing Java code, and there's a *lot* of existing Java code.  One
might as well suggest improving Java by making integer overflow throw an
exception the way division by zero does: That would be an improvement,
I think (if accompanied by non-overflowing `unsigned' types), but there
is simply no way such a change could be contemplated at this late date.

     If you're interested in designing a language that improves upon Java
you might certainly choose a different scheme for handling exceptional
circumstances.  Note that it would be difficult to make a non-exception
language run on the JVM because the JVM is *required* to throw actual
Java exceptions in certain circumstances, but there might be ways to
intercept those and convert them to your language's preferred form.  Or,
of course, you could use something other than the JVM as your substrate.

     But changing Java so as to invalidate the many millions of lines of
existing code and re-spend the many millions of Flanian Pobble Beads
already invested in developing them?  Not a chance.  No way.  No.

-- 
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#30196

@Eric
>      I'm sorry if I have wronged you.  
No problem.

>      But changing Java so as to invalidate the many millions of lines of
> existing code and re-spend the many millions of Flanian Pobble Beads
> already invested in developing them?  Not a chance.  No way.  No.
I think the new exception mechanism can be implemented in a backward compatible way:

1. mark the current Throwable and its sub-types deprecated 
2. you can still catch (Thowable ex) but mark this usage as deprecated 
3. you can convert a Throwable to Fault by: Fault.naturalize(Throwable ex).  The class name of the Throwable caught will be the code.  The original exception will be set as cause of the new Fault.

I implemented a simulation library (though not efficient at all): https://github.com/pahakia/lib

The new catch syntax is: catch(FaultCode, Fault fault).  The existing catch(Throwable ex) will be marked as deprecated (I don't know how though).

[toc] | [prev] | [next] | [standalone]

#30187

On Sunday, 26 October 2014 05:15:34 UTC-4, rossum  wrote:
> On Sun, 26 Oct 2014 08:09:10 +0100, Joerg Meier 
> wrote:
> 
> >> 2. this code information currently is implemented partly as
> >> exception type.  But that is not enough, so some projects augment
> >> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
> >
> >That link leads to a dead/empty page.
> You need to include the final "(ELUG)" in the URL, then it works.
> 
> rossum

Thanks.  I didn't realize there are 2 brackets at the end.

[toc] | [prev] | [next] | [standalone]

#30188

On Sun, 26 Oct 2014 12:06:07 -0700 (PDT), boxzou@gmail.com wrote:

> On Sunday, 26 October 2014 05:15:34 UTC-4, rossum  wrote:
>> On Sun, 26 Oct 2014 08:09:10 +0100, Joerg Meier 
>> wrote:
>>>> 2. this code information currently is implemented partly as
>>>> exception type.  But that is not enough, so some projects augment
>>>> it with code like in SQLException (e.g. https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)).
>>>That link leads to a dead/empty page.
>> You need to include the final "(ELUG)" in the URL, then it works.
> Thanks.  I didn't realize there are 2 brackets at the end.

The second one really belongs there - it's the closing bracket from the
(e.g... part, it's just not obvious when you copy the link while being half
asleep ;)

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#30189

Here is a JPA exception I once tried to recover from (catch) ('a ->b' means b is a cause of a as in exception chaining):
   PersistenceException -> DatabaseException -> BatchUpdateException -> SQLIntegrityConstraintViolationException

And in the ultimate cause 'SQLIntegrityConstraintViolationException', there is a code 'ORA-00001' which mean unique constraint violated.

So I have to drill down all the way to find the ultimate cause, even on that one if I had to make sure, I would have called getCode() to see if it is 'ORA-00001'.

An if I switch from Oracle DB to Derby DB, the chain of exceptions would be:
  PersistenceException -> DatabaseException -> BatchUpdateException -> SQLIntegrityConstraintViolationException -> EmbedSQLException -> StandardException

Why do we have this kind of chaining?  because Java has checked exceptions.  But even if we do away with checked exceptions, the exception type alone still is not sufficient to handle the exception.  We still need to get a code to know exactly what happened.  And even with a code, e.g. unique constraint violated, but which unique constraint?  The constraint name is buried in the message, which is unstructured data.  I want structured data.

So I want to be able to get to the real cause of the problem (i.e. code ORA-00001) with just the catch statement (compare to catch just get the exception, then get the code, and how to get the code is not standardized at all).  And structured data like the name of the unique constraint.  And a standardized way to get the structured data instead of some Ad Hoc way.

That's why I propose:

Fault(FaultCode, String...structuredData)
FaultCode(String, numArgs, messageTemplate)

messageTemplate serves as:
1. documentation
2. I18N (optional)

numArgs is the number of placeholders i.e. '{n}' in messageTemplate.  The length of structuredData must be equal to numArgs.

Since I believe checked exception is bad, there is no point for compile time checking if correct exception is caught.

I think both JDBC and JPA implementers run into the scalability problem because instead of implementing every exception condition, they used the code approach.

EclipseLink/JPA codes:  https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_(ELUG)
Oracle/JDBC codes: http://docs.oracle.com/cd/B10501_01/java.920/a96654/ermesap.htm

To summarize:

1. do away with checked exception
2. One exception type and only one: Fault
3. One and only one exception code type: FaultCode
4. a parameter list in Fault for structured data
5. new catch syntax: catch(someFaultCode, Fault fault)

Backward compatibility can be maintained by:

1. mark the current Throwable and its sub-types deprecated
2. you can still catch (Thowable ex) but mark this usage as deprecated
3. you can convert a Throwable to Fault by: Fault.naturalize(Throwable ex)

[toc] | [prev] | [next] | [standalone]

#30192

Exception when happened has to be dealt with either by software or human (developer debugging etc).

I think every developer must have been frustrated by some tool throwing exception but the exception is too vague about what exactly had gone wrong.  A lot of us also spent so much time debugging a problem because some exception was swallowed.

If the exact cause is clear at the first sight, it would save every one significant time.

The problem exceptions are swallowed is caused by 
1. checked exception forces you to catch.  And in case you're not careful enough, it's swallowed
2. across system boundary especially remote systems.  Effort has to be made to propagate exception across system boundary.  But a project focusing on success path barely tests any failure path.
3. losing stack trace, stack trace may times is much more valuable than exception message because it pinpoints where the failure happened.  But usually developer just catch the exception and log the message without the stack trace.  If we reuse exception messages, it's hard to know where failure happened resulting in many hours or even days of developer time wasted.

Another problem is duplicated exception logging.  exception logging is one kind of exception handling.  Ideally an exception should be logged just ONCE.  But developer is so afraid of the exception gets swallowed up the stack, they catch the exception, log it and rethrow it (or chain it to a new exception and throw the new exception).

All these problems can be significantly alleviated once:
1. checked exception is removed
2. the new mechanism (Fault/FaultCode) is implemented.

[toc] | [prev] | [next] | [standalone]

#30193

boxzou@gmail.com wrote:
> 
> Why do we have this kind of chaining?  because Java has checked exceptions.

No, this issue has nothing to do with checked exceptions. You'll have this
problem every time you put a number of different implementations and third
party products behind a generic interface.

The problem is simply that the various error modes that can occur "under 
the hood" is not known at the point where the call is made, because the
calling code doesn't know (nor does it care) which underlying implementation
is actually in use.

It doesn't matter how you describe the error codes -- strings, Exception
objects in a type hierarchy, integer codes or Klingon limerick -- you'll
end up with a hierarcy of error types, where the calling code has to deal
with information loss about the actual, low-level error mode.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30195

@Leif

What if we don't catch third party exceptions and let them pass through, aren't they the true cause of the failure? then there is no information loss.  What's wrong with this approach?

On Sunday, 26 October 2014 17:50:28 UTC-4, Leif Roar Moldskred  wrote:
> > 
> > Why do we have this kind of chaining?  because Java has checked exceptions.
> 
> No, this issue has nothing to do with checked exceptions. You'll have this
> problem every time you put a number of different implementations and third
> party products behind a generic interface.
> 
> The problem is simply that the various error modes that can occur "under 
> the hood" is not known at the point where the call is made, because the
> calling code doesn't know (nor does it care) which underlying implementation
> is actually in use.
> 
> It doesn't matter how you describe the error codes -- strings, Exception
> objects in a type hierarchy, integer codes or Klingon limerick -- you'll
> end up with a hierarcy of error types, where the calling code has to deal
> with information loss about the actual, low-level error mode.
> 
> -- 
> Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30197

On Sun, 26 Oct 2014 12:46:59 -0700, boxzou wrote:

> Here is a JPA exception I once tried to recover from (catch) ('a ->b'
> means b is a cause of a as in exception chaining):
>    PersistenceException -> DatabaseException -> BatchUpdateException ->
>    SQLIntegrityConstraintViolationException
> 
> And in the ultimate cause 'SQLIntegrityConstraintViolationException',
> there is a code 'ORA-00001' which mean unique constraint violated.
> 
> So I have to drill down all the way to find the ultimate cause, even on
> that one if I had to make sure, I would have called getCode() to see if
> it is 'ORA-00001'.
>
Yes, you do have to deal with all the exceptions in that list - and its 
nothing to do with Java specifically.

You are seeing this exception list because this is the behaviour of every 
RDBMS I've used: when an RDBMS throws an exception, that is merely the 
head of a list of related exceptions. To properly report what went wrong 
you have to work down the list, reporting the exception name and error 
message contained in each SQL exception in the list. That is required by 
the way that almost every RDBMS works.

Since an ODBC driver is a machine independent RDBMS interface, it follows 
that it also reports SQL exceptions by returning a reference to a list of 
exceptions. And, since a JDBC driver class follows the ODBC structure 
very closely and in many cases is implemented as an ODBC wrapper, it does 
the same. 

> An if I switch from Oracle DB to Derby DB, the chain of exceptions would
> be:
>   PersistenceException -> DatabaseException -> BatchUpdateException ->
>   SQLIntegrityConstraintViolationException -> EmbedSQLException ->
>   StandardException
> 
Of course: Oracle, Derby (and MySQL, MariaDB, PostgreSQL, SQLserver, 
Sybase, DB2, HSQL) are independently developed proprietary RDBMS (only 
PostgreSQL, HSQL and MariaDB are open source; MySql used to be), so their 
implementations are, of course different and so are the exceptions they 
throw in similar circumstances.

> Why do we have this kind of chaining?  because Java has checked
> exceptions.
>
Bollocks. You see it when using with JDBC or Reflection as RDBMS 
interfaces because this is what any RDBMS needs to do if it is to return 
an accurate description of what caused an SQL exception.

The *only* place you'll see such a chain in pure Java is 
when a higher level class catches an exception thrown by a method of a 
lower level class it called and, instead of dealing with the exception 
and throwing a more meaningful exception, chooses to build a chain by 
throwing an Exception containing its explanation plus a link to the 
Exception that it caught. I can't offhand think of many Java standard 
library classes that do this, but you *should* look for and follow these 
chains wherever they might be found if you use 3rd party class libraries. 
Yes, they should document their uses of such Exception chains, but they 
may have forgotten to do so. All RDBMS implement such chains and 
*document* the fact that they do so it should not come as a surprise.

   
> But even if we do away with checked exceptions, the
> exception type alone still is not sufficient to handle the exception. 
>
Disagree. 

Name or code, its utterly irrelevant which you get handed provided its 
unique. In C you get a (hopefully unique) exit code and are left to 
decide whether you want to handle it of not. In Java, you *must* catch a 
checked Exception but its up to you whether you're a lazy wazzock and 
deal with all Exceptions in a single portmanteau catch() clause or 
whether you are more careful and differentiate their handling with a set 
of catch() clauses.

> We still need to get a code to know exactly what happened.
>
Yeah. Its called the Exception name.

> with a code, e.g. unique constraint violated, but which unique
> constraint?  The constraint name is buried in the message, which is
> unstructured data.  I want structured data.
>
Sorry, but that's not what any RDBMS does. Live with it: its probably[1] 
written into the current SQL specification and is not going to change.
 
[1] 'probably', because the SQL standard is a paid-for document and I 
don't have access to a copy.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30198

@Martin

If there is no checked exception, you don't need to wrap and wrap and wrap.  Just let the exception pass through.  Handle it only if you can.

On Sunday, 26 October 2014 21:06:05 UTC-4, Martin Gregorie  wrote:
> On Sun, 26 Oct 2014 12:46:59 -0700, boxzou wrote:
> 
> > Here is a JPA exception I once tried to recover from (catch) ('a ->b'
> > means b is a cause of a as in exception chaining):
> >    PersistenceException -> DatabaseException -> BatchUpdateException ->
> >    SQLIntegrityConstraintViolationException
> > 
> > And in the ultimate cause 'SQLIntegrityConstraintViolationException',
> > there is a code 'ORA-00001' which mean unique constraint violated.
> > 
> > So I have to drill down all the way to find the ultimate cause, even on
> > that one if I had to make sure, I would have called getCode() to see if
> > it is 'ORA-00001'.
> >
> Yes, you do have to deal with all the exceptions in that list - and its 
> nothing to do with Java specifically.
> 
> You are seeing this exception list because this is the behaviour of every 
> RDBMS I've used: when an RDBMS throws an exception, that is merely the 
> head of a list of related exceptions. To properly report what went wrong 
> you have to work down the list, reporting the exception name and error 
> message contained in each SQL exception in the list. That is required by 
> the way that almost every RDBMS works.
> 
> Since an ODBC driver is a machine independent RDBMS interface, it follows 
> that it also reports SQL exceptions by returning a reference to a list of 
> exceptions. And, since a JDBC driver class follows the ODBC structure 
> very closely and in many cases is implemented as an ODBC wrapper, it does 
> the same. 
> 
> > An if I switch from Oracle DB to Derby DB, the chain of exceptions would
> > be:
> >   PersistenceException -> DatabaseException -> BatchUpdateException ->
> >   SQLIntegrityConstraintViolationException -> EmbedSQLException ->
> >   StandardException
> > 
> Of course: Oracle, Derby (and MySQL, MariaDB, PostgreSQL, SQLserver, 
> Sybase, DB2, HSQL) are independently developed proprietary RDBMS (only 
> PostgreSQL, HSQL and MariaDB are open source; MySql used to be), so their 
> implementations are, of course different and so are the exceptions they 
> throw in similar circumstances.
> 
> > Why do we have this kind of chaining?  because Java has checked
> > exceptions.
> >
> Bollocks. You see it when using with JDBC or Reflection as RDBMS 
> interfaces because this is what any RDBMS needs to do if it is to return 
> an accurate description of what caused an SQL exception.
> 
> The *only* place you'll see such a chain in pure Java is 
> when a higher level class catches an exception thrown by a method of a 
> lower level class it called and, instead of dealing with the exception 
> and throwing a more meaningful exception, chooses to build a chain by 
> throwing an Exception containing its explanation plus a link to the 
> Exception that it caught. I can't offhand think of many Java standard 
> library classes that do this, but you *should* look for and follow these 
> chains wherever they might be found if you use 3rd party class libraries. 
> Yes, they should document their uses of such Exception chains, but they 
> may have forgotten to do so. All RDBMS implement such chains and 
> *document* the fact that they do so it should not come as a surprise.
> 
>    
> > But even if we do away with checked exceptions, the
> > exception type alone still is not sufficient to handle the exception. 
> >
> Disagree. 
> 
> Name or code, its utterly irrelevant which you get handed provided its 
> unique. In C you get a (hopefully unique) exit code and are left to 
> decide whether you want to handle it of not. In Java, you *must* catch a 
> checked Exception but its up to you whether you're a lazy wazzock and 
> deal with all Exceptions in a single portmanteau catch() clause or 
> whether you are more careful and differentiate their handling with a set 
> of catch() clauses.
> 
> > We still need to get a code to know exactly what happened.
> >
> Yeah. Its called the Exception name.
> 
> > with a code, e.g. unique constraint violated, but which unique
> > constraint?  The constraint name is buried in the message, which is
> > unstructured data.  I want structured data.
> >
> Sorry, but that's not what any RDBMS does. Live with it: its probably[1] 
> written into the current SQL specification and is not going to change.
>  
> [1] 'probably', because the SQL standard is a paid-for document and I 
> don't have access to a copy.
> 
> 
> -- 
> martin@   | Martin Gregorie
> gregorie. | Essex, UK
> org       |

[toc] | [prev] | [next] | [standalone]

#30199

boxzou@gmail.com wrote:
> @Martin
> 

> If there is no checked exception, you don't need to wrap and wrap and wrap.  
> Just let the exception pass through.  Handle it only if you can.


Then the client code is going to look like this:

  ...
  try {
    return toDomainObject( sqlStatement.executeQuery( query ) );
  }
  catch (MySQLException | MariaDBException | PostgresException |
         SQLLiteException | OraleDBException | SQLServerException |
         DB2Exception | InformixException | TeradataException |
         HSQLException | H2Exception | DerbyException | ... )

And then three weeks after you've published your product, someone is
going to make a new database that you'll have to add support for.

There is a _reason_ why we abstract away the specific, vendor
specific error modes into a hierarcy of ever more generic error
types: we want to be able to react intelligently to errors even
when we don't know what the exact, low-level errors that can
occur _are_.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30201

We use Oracle for prod and derby for dev.  I already have to go into the details of either Oracle or derby exception.  It's impossible to hide the details.  

Look at how many error code in derby and oracle.  Map an exception IS handling the exception.  You can only map a few and usually you still need to attach the original exception as cause in the new exception (you should just for the sake of stack trace).  If you are writing new library on top of EclipseLink, can you imagine mapping all those error codes onto something in your library?  It is both tedious and unnecessary.

Just let the exception fly through.  Without checked exception, you will not be forced to catch any exception.  Only catch the exceptions that you CAN handle (don't even try to log it, let the server or a global default exception handle in a standalone app to log it).  There will be lots of useless catch statements saved and enough to compensate for the extra few catches (or | exception types) when you are serious recover from a failure.

If we are lucky that the JPA or JDBC can publish a bunch of standard fault codes for common exceptions, the ugly multiple catch is not necessary.  The chained exceptions I showed in my previous post is a very common case, and yet without standardization I still have to go to the causes :(

On Monday, 27 October 2014 01:13:13 UTC-4, Leif Roar Moldskred  wrote:
> box...@gmail.com wrote:
> > @Martin
> > 
> 
> > If there is no checked exception, you don't need to wrap and wrap and wrap.  
> > Just let the exception pass through.  Handle it only if you can.
> 
> 
> Then the client code is going to look like this:
> 
>   ...
>   try {
>     return toDomainObject( sqlStatement.executeQuery( query ) );
>   }
>   catch (MySQLException | MariaDBException | PostgresException |
>          SQLLiteException | OraleDBException | SQLServerException |
>          DB2Exception | InformixException | TeradataException |
>          HSQLException | H2Exception | DerbyException | ... )
> 
> And then three weeks after you've published your product, someone is
> going to make a new database that you'll have to add support for.
> 
> There is a _reason_ why we abstract away the specific, vendor
> specific error modes into a hierarcy of ever more generic error
> types: we want to be able to react intelligently to errors even
> when we don't know what the exact, low-level errors that can
> occur _are_.
> 
> -- 
> Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#30211

In article 5sednVQ7leDCSdDJnZ2dnUVZ8lWdnZ2d@giganews.com, Leif Roar
Moldskred <leifm@huldreskog.localdomain> wrote:

> There is a _reason_ why we abstract away the specific, vendor specific
> error modes into a hierarcy of ever more generic error types: we want to
> be able to react intelligently to errors even when we don't know what
> the exact, low-level errors that can occur _are_.

I'd be more interested in knowing why there are specific, vendor specific 
error modes for even those errors that can happen with every RDBMS. 
Including the OP's example of a primary key uniqueness constraint 
violation. Why is there not a standardized set of exception classes in, 
say, java.sql for the universal, vendor-independent errors? The existing 
chaining would still be needed to handle the rest, of course.

[toc] | [prev] | [next] | [standalone]

#30213

Marketa Jadalova <m-jadalova3@gmail.com> wrote:
> 
> I'd be more interested in knowing why there are specific, vendor specific 
> error modes for even those errors that can happen with every RDBMS. 
> Including the OP's example of a primary key uniqueness constraint 
> violation. Why is there not a standardized set of exception classes in, 
> say, java.sql for the universal, vendor-independent errors? The existing 
> chaining would still be needed to handle the rest, of course.

Basically because the JDBC API is old and pretty badly done. The lack of
good error mode descriptions at an appropriate level of abstraction is
just _one_ of the many issues it has. It really is time we got new and 
improved API for database connections.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web