Can we add a getColumn method to SQLException ?

[Mark Rotteveel]

On 25/01/2024 15:36, West Farmer wrote:
> Hi, JDBC experts!
> I am just an ordinary Java developer. When I designed my Restful 
> interface, I defined the following response entities:
> {
>      code: "the response code"，
>      emsg: "the user friendly error message"，
> eproperty: "the property of the entity which causing the error "
> }
> For example, when the client code updates a user's email address through 
> my Restful interface, if the email address already exists, I want to 
> return an error like the following:
> {
>      code: 400001,
> emsg: "email address already taken",
> eproperty: "email"
> }
> Typically, the database side defines uniqueness constraints for the 
> corresponding fields of the email.
> However, I found that through the existing JDBC API, it seems not easy 
> to parse the corresponding field names from the errors returned by the 
> database, especially considering the need to support different types of 
> databases.
> Similar functions have been implemented in the JDBC drivers of some 
> databases, such as postgresql. Its PSQLException class 
> inheritsjava.sql.SQLException, we can get a ServerErrorMessage, and this 
> class provides the getColumn method to get the field name that caused 
> the error.
> Can we add apublic Optional<String> getOptionalCausingColumnmethod to 
> SQLException?

That wouldn't make sense to me, as

1) there are a lot more causes for SQLExceptions that don't involve 
columns, so having that on the root SQLException would IMHO pollute the 
class.

2) There is a wide variety of databases, and adding something like this 
to be usable would require that drivers can actually identify the column 
involved, and I _guess_ that is often not the case.

Also, it seems Oracle has gotten rather silent on JDBC, even some of the 
other proposals done here or on the EG list doesn't seem to have 
triggered anything to start a JDBC 4 maintenance update 4 (or JDBC 4.4) 
or JDBC 5, so it is unlikely anything like this will surface.


However, the idea has some merit, but then I would rather want a more 
flexible way to get properties from an exception (to not add to methods, 
but also maximize flexibility)

Maybe something like:

interface SQLExceptionDataKey<T> {
    String vendor();
    String name();
    Class<T> type();
}

or

record SQLExceptionDataKey<T>(String vendor, String name, Class<T> type) {}

and then have in SQLException:

<T> Optional<T> getData(SQLExceptionDataKey<T> key)

and some ways to set or provide the data items in the constructor

(Maybe there need to be some supers or extends in those generics, I can 
never get it right when writing this the first time.)

And maybe some "standard" keys.

On the other hand, while flexible, this feels very convoluted, and I 
suspect it will unlikely get implemented, or support so spotty and 
varying, that there is hardly a good reason to actually use it.


TL;DR, don't hold your breath, and write a driver- or database-specific 
solution.

Mark
-- 
Mark Rotteveel