Hi,
InterruptedException should be rewrapped only very carefully. When you
receive InterruptedException it means "this thread must die", so if
you have to rethrow something else due signature issues to you should
rethrow something that nobody will catch and swallow. I'd rethrow a
bare RuntimeException in need be.
Florent
On Mon, Aug 12, 2013 at 6:22 PM, Dave Cramer <pg@fastcrypt.com> wrote:
> Ok, so you would like the code to not reset the interrupted exception so
> that when it returns the interrupted bit will still be set and you can check
> for isInterrupted ?
>
> The SQL error is rather vague here since it is not really a SQL error,
> rather someone cancelled the thread.
>
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Fri, Aug 9, 2013 at 4:35 AM, Andreas Rudolph
> <andreas.rudolph@spontech-spine.com> wrote:
>>
>> Hi there!
>>
>> + JDBC driver build number
>> 9.1-903
>>
>> + Server
>> PostgreSQL 9.1.9 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Debian
>> 4.4.5-8) 4.4.5, 32-bit
>>
>> + Error message / stack trace
>>
>> org.postgresql.util.PSQLException: Beim Verbindungsversuch trat eine
>> Unterbrechung auf.
>> at org.postgresql.Driver$ConnectThread.getResult(Driver.java:365)
>> at org.postgresql.Driver.connect(Driver.java:269)
>> …
>>
>> + Description
>>
>> Recently I discovered this problem because it prevents to tell other
>> SQLExceptions and interruption apart (in the exception handlers). After
>> examining the source of org.postgresql.Driver I noticed that
>> org.postgresql.Driver$ConnectThread.getResult catches InterruptedException
>> and throws a org.postgresql.util.PSQLException instead BUT without supplying
>> the InterruptedException as the cause (exception chaining) and without
>> resetting the interrupted flag via Thread.currentThread().interrupt() (SQL
>> error code / SQL state is unspecific, too). Please note that this behavior
>> is present in 9.2-1003, too.
>>
>> Therefore I suggest that the handling of InterruptedException should be
>> changed so it becomes more interoperable with client code that needs to
>> handle SQLExceptions differently from thread interruption -- in a concurrent
>> environment an already scheduled database query may become obsolete before
>> it finishes because another query may be needed for example because of user
>> intervention.
>>
>> Greetings
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87