Programmatically handling error H2 codes in Eclipse/OSGi

[mgd]

I am trying to programmatically handle errors thrown as SQLExceptions
from H2 when using H2 as part of an Eclipse project.

Calling SQLException.getErrorCode() gives me the H2 error code which I
would like to match against the constants in class
org.h2.constant.ErrorCode. Unfortunately, this class is not exported
from the h2.jar (which is packaged as a valid OSGi bundle).

Here is the relevant line from MANIFEST.MF:

Export-Package:
org.h2,org.h2.api,org.h2.fulltext,org.h2.jdbcx,org.h2.tools,org.h2.util

Is there another way of getting to the error codes?

/Martin

[Thomas Mueller]

Hi,

What kind of errors do you need to handle?

In theory, your application should be written so that it works with all databases. I know this is not always possible... In a perfect world, all databases would return the same SQL state for the same exception, and the list of SQL states would be part of the JDBC API (similar to java.sql.Types).

If hardcoding the SQL state in your application is not an option, I could move the ErrorCode class to org.h2.api, the other (easier) solution is to include org.h2.constant.* to the list of exported packages. But first I would like to better understand the problem.

Regards,
Thomas

[András Péteri]

Hello,

in Eclipse's CDO project, unique key violations are detected by extracting the SQL state from the caught exception, differences in reported codes are handled by database adapter classes. Making ErrorCode available would help maintain consistent behaviour for different versions of H2; please see the related bug report at [1].

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=369775

--

András

[Thomas Mueller]

Hi,

Sorry for the delay. I see the problem now. The error code was changed
because originally H2 didn't use the "correct" (as defined by the SQL
standard) value. There are multiple solutions:

- move the ErrorCode class to org.h2.api

- use SQLIntegrityConstraintViolationException instead of SQLException

Which one would you prefer? Or would it make sense to do both?

Regards,
Thomas

2012/2/29 András Péteri <ape...@b2international.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "H2 Database" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/h2-database/-/EtuaGZaaAHwJ.
>
> To post to this group, send email to h2-da...@googlegroups.com.
> To unsubscribe from this group, send email to
> h2-database...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/h2-database?hl=en.

[András Péteri]

Thomas,

Thank you for the response! With respect to the enhancement request in CDO, a moderate amount of discussion has been going on there, so if you have some additional time to spend, please go through the comments. Key points are:

* The Eclipse Orbit-maintained bundle of h2 (version 1.1.117) exported the package org.h2.constant;

* SQLIntegrityConstraintViolationException was introduced in Java 6 and CDO needs to support version 5, so that doesn't help in their case;

* Moving ErrorCode to org.h2.api would create a version dependency which defeats the original purpose of using it (i.e. keeping compatibility with earlier versions, including the one in Orbit while handling changes in error codes automatically);

* The most probable fix at this point is checking for both error codes as string literals without referring to ErrorCode, as the values themselves are not expected to change frequently, nor collide with any other state in future versions.

(Disclaimer: I'm the reporter of the aforementioned issue, and may not interpret every notion and comment correctly.)

On Sat, Mar 17, 2012 at 11:37 AM, Thomas Mueller <thomas.to...@gmail.com> wrote:

Hi,

Sorry for the delay. I see the problem now. The error code was changed
because originally H2 didn't use the "correct" (as defined by the SQL
standard) value. There are multiple solutions:

- move the ErrorCode class to org.h2.api

- use SQLIntegrityConstraintViolationException instead of SQLException

Which one would you prefer? Or would it make sense to do both?

Regards,
Thomas

--
András

[Thomas Mueller]

Hi,

My current plan it to move the ErrorClass to org.h2.api in H2 version 1.4.x. At some later date (once Java 5 is no longer be supported), SQLException sub-classes (SQLIntegrityConstraintViolationException and so on) will be used.

Regards,

Thomas

--

You received this message because you are subscribed to the Google Groups "H2 Database" group.