pgjdbc/pgjdbc GitHub issues and pull requests (mirror)help / color / mirror / Atom feed
[pgjdbc/pgjdbc] issue #3779: SQLException subclasses support 3+ messages / 2 participants [nested] [flat]
* [pgjdbc/pgjdbc] issue #3779: SQLException subclasses support @ 2025-08-20 18:17 "ivan-ra (@ivan-ra)" <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: ivan-ra (@ivan-ra) @ 2025-08-20 18:17 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> SQLException class has many descendants: SQLRecoverableException, SQLSintaxErrorException, SQLTimeoutException, etc... Application developer can catch this exceptions in code to do specific processing. But for now pgjdbc driver for all errors raises only PSQLException. Of course, it possible to find exception cause by parsing exception message, but it requires custom code, It makes postgres exception handling non-portable. It would be nice if the driver could find the cause of the error on its own and throw a corresponding exception. Do you have plans to support all (or some) SQLException subclasses? ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3779: SQLException subclasses support @ 2025-08-20 18:48 ` "vlsi (@vlsi)" <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: vlsi (@vlsi) @ 2025-08-20 18:48 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> The culprit is that `PSQLException extends SQLException`, and we have tons of code that already catch `PSQLException` or cast `Throwable` to `PSQLException`. `PSQLException` predates `SQLRecoverableException`, so I would rather say JDBC spec is not backward-compatible when it comes to `SQLException` subtypes. Note that a single application might have **multiple** libraries that are either prepared or unprepared to `SQLRecoverableException`. I've asked ChatGPT, and it did not provide trivial approach to migrating pgjdbc to exception subtypes: https://chatgpt.com/share/68a6162a-8ca4-800f-a0db-a8e5ab0651df I don't think a connection-wide property like `throw_exceptions_as=psqlexception | psqlexception_subtypes` is not viable as, well, there might be multiple libraries which are either prepared or unprepared to throwable subtypes. ---- I think it might be a nice idea to have a mapper utility which would take `PSQLException` as an input and produce typed exception in return. It won't be completely portable though. Do you have any other suggestion? ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [pgjdbc/pgjdbc] issue #3779: SQLException subclasses support @ 2025-08-20 19:24 ` "ivan-ra (@ivan-ra)" <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: ivan-ra (@ivan-ra) @ 2025-08-20 19:24 UTC (permalink / raw) To: pgjdbc/pgjdbc <[email protected]> I was thinking about the driver wrapper: ``` my.awesome.Driver extends org.postgresql.Driver ``` It could also produce proxy classes for Connection, Statement, etc that would throw the required exceptions (at the moment i only want to catch only SQLTimeoutException). In the application configuration it would be enough to replace driver class name. Probably writing such a wrapper will really not be trivial. Mapper utility is good suggestion ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-08-20 19:24 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-08-20 18:17 [pgjdbc/pgjdbc] issue #3779: SQLException subclasses support "ivan-ra (@ivan-ra)" <[email protected]> 2025-08-20 18:48 ` "vlsi (@vlsi)" <[email protected]> 2025-08-20 19:24 ` "ivan-ra (@ivan-ra)" <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox