You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an app that connects to multiple PG instances. When a pg client/pool encounters an error, the only way to know which database was the culprit is to have a handle to the Client/Pool object. But often times your error handling code does not have a handle to the Client/Pool objects (by its nature, error handling code is often disconnected from the code that threw the error). The only thing error handling has a handle to is the error itself.
An example:
try{awaitdoSomethingWithVariableDb();}catch(err){// This does not currently work.console.error("Error doing something with DB "+err.host);}
It would be nice if pg included this target host info on errors. Alternatively, pg could include the associated Client and/or Pool object on the error. Although that seems more prone to leaking memory.
The text was updated successfully, but these errors were encountered:
I have an app that connects to multiple PG instances. When a
pg
client/pool encounters an error, the only way to know which database was the culprit is to have a handle to the Client/Pool object. But often times your error handling code does not have a handle to the Client/Pool objects (by its nature, error handling code is often disconnected from the code that threw the error). The only thing error handling has a handle to is the error itself.An example:
It would be nice if
pg
included this target host info on errors. Alternatively,pg
could include the associatedClient
and/orPool
object on the error. Although that seems more prone to leaking memory.The text was updated successfully, but these errors were encountered: