java.sql2.SqlException

Lukas Eder lukas.eder at gmail.com
Mon Oct 9 07:36:30 UTC 2017


I'm not sure how I missed this when I reviewed the API, but I most
certainly agree with Philippe's points 1) and 3)

The dependency on java.sql was also discussed in the context of having an
independent (or not) JdbcType class:
http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/
2017-October/000105.html

As far as checked exceptions are concerned, they were indeed the wrong
choice for all things related to system exceptions (which includes the old
SQLException and IOException).

I don't have an opinion on 2) naming :)

Thanks,
Lukas

2017-10-09 9:18 GMT+02:00 Philippe Marschall <pm at netcetera.ch>:

> 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
>


More information about the jdbc-spec-discuss mailing list