Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: redesign exception Date: Mon, 27 Oct 2014 01:05:43 +0000 (UTC) Organization: A noiseless patient Spider Lines: 94 Message-ID: References: <1d6fc97wumvl6$.316nwmuziazw.dlg@40tude.net> <6e29c258-9842-4c60-9d99-9929a92d7a96@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Mon, 27 Oct 2014 01:05:43 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="30284"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192iLOO4WB4mz1vF8WZXS8WeES58p7pQzA=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:nRHoRXdNe/p1FoTyIlSbhrurWUE= Xref: csiph.com comp.lang.java.programmer: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 |