Error handling, SQL codes and states in Glorp exceptions

Hi there,

this is just an idea and suggestion and I'd like to hear your opinions.

I think Glorp's Exceptions could be improved a lot if the had special variables for SQL Codes and States. I think it is not enough to get an ExGlorpReadException that contains a String which includes SQL codes and states.

Example:

Sometimes, a database connection gets lost. Be it due to some network problem or the server being down or some other problem. If I only get a Glorp Read or Write exception, it is "hard" to decide whether this is a resolvable situation or not. As it is now, this exception is just the same as if the mappings were wrong or some other problem occured which means changes to the code. Some excptions, however, can possibly be resolved by re-connecting or such.

So I'd either like to have a new Exception Class for DB Errors (something went wrong beneath "Glorp") and one for "real" Glorp Errors (inconsisten values in Field, no table initalizer found, etc.). Or at least I think we should have variables in GlorpExceptions that transport a possible DB exception's data, like SQLCode and SQLState.
 
Sure, I can go and parse the Exceptions' descriptove text for SQLCode and SQL State and whatever. But it feels so wrong ;-)

Any thoughts?


Joachim

... or is this only a problem in Instantiations' port of Glorp to VA ST? Does Glorp on VW or Pharo provide better exceptions?

So it seems the error codes in Glorp are not a problem for other users. Seems you solved the problems

How do you guys find out if a GlorpReadException is due to a database connection loss or such? Do you scan the Strings for patterns like 'SQLCODE=' and build a lot of machinery on top of that?

I'm really interested to hear what people do to reconnect at the right occasions or issue reorgs or such.


Joachim



Am Donnerstag, 18. Januar 2018 09:08:39 UTC+1 schrieb jtuchel:

Hi there,

this is just an idea and suggestion and I'd like to hear your opinions.

I think Glorp's Exceptions could be improved a lot if the had special variables for SQL Codes and States. I think it is not enough to get an ExGlorpReadException that contains a String which includes SQL codes and states.

Example:

Sometimes, a database connection gets lost. Be it due to some network problem or the server being down or some other problem. If I only get a Glorp Read or Write exception, it is "hard" to decide whether this is a resolvable situation or not. As it is now, this exception is just the same as if the mappings were wrong or some other problem occured which means changes to the code. Some excptions, however, can possibly be resolved by re-connecting or such.

So I'd either like to have a new Exception Class for DB Errors (something went wrong beneath "Glorp") and one for "real" Glorp Errors (inconsisten values in Field, no table initalizer found, etc.). Or at least I think we should have variables in GlorpExceptions that transport a possible DB exception's data, like SQLCode and SQLState.
 
Sure, I can go and parse the Exceptions' descriptove text for SQLCode and SQL State and whatever. But it feels so wrong ;-)

Any thoughts?


Joachim

... or is this only a problem in Instantiations' port of Glorp to VA ST? Does Glorp on VW or Pharo provide better exceptions?