java.sql2.SqlException

[Douglas Surber]

All good points.  The module issue may be the deciding factor.

I don’t think SqlException is actually used anywhere in the API except as a superclass of SqlSkippedException which shows up only as an argument to Operation.onError so checked/not-checked hardly matters. Further elaboration of the error handling system would most likely specify that for database errors the arguments to Operation.onError would be SqlException (or TBD subclasses). Again shows up only as an argument so checked/not-checked is less important. Still the point is well taken.

Douglas


> On Oct 9, 2017, at 12:17 AM, Philippe Marschall <philippe.marschall at netcetera.com> wrote:
> 
> Hello
> 
> I think SqlException extending SQLException is not ideal for several reasons
> 
> 1. It introduces a dependency on the java.sql module which in term brings dependencies to the java.xml and java.logging modules. This sorta, kinda defeats the idea behind building minimal runtime images.
> 
> 2. It is super confusing to have two different capitalisations (I realize JDBC does not follow Java naming conventions).
> 
> 3. It is a checked exception. There is broad consensus that checked exceptions in practice do not bring the benefits once envisioned plus bring a lot of downsides. All the new APIs that I'm aware of use runtime / unchecked exceptions instead of checked exceptions. This is especially true for all the functional/stream interfaces in Java 8, hence things like java.io.UncheckedIOException.
> 
> Cheers
> Philippe