I’ve been pondering this recently and was wondering what other folks do to provide a consistent approach to reporting database related errors (Although this could be used for other things as well I suppose).
Im working on a simple database related app that has a ‘db’ module. Within that module, I have a ‘DBOpen’ method and 2 global properties ‘LastErrorCode’ and ‘LastErrorDescription’.
The first thing I do in ‘DBOpen’ is to check for FolderItemExists.
After this check, I set the database parameters and call DB.Connect.
If either of these fail, I put the error code & description into LastErrorCode and LastErrorDescription respectively, and then call a simple sheetwindow using ShowModalWithin which displays the error information and allows a clean exit from the app or return to a previous screen.
I’ll be using the same method when executing sql.
Error window example
It works exactly as expected, and I’ve been able to trip the errors for the purpose of basic testing and all is fine.
Does this seem a reasonable approach to manage error reporting to the end user, or is there a better method ?
[quote=436477:@Stephen Thomas]I’ll be using the same method when executing sql.
Does this seem a reasonable approach to manage error reporting to the end user, or is there a better method ?[/quote]
If you’re using the same method you’re doing great! The less copy / paste code you have, the easier it is to maintain, so a central function for checking errors is the way to go about it.
If you’ve ever used ARGen from BKeeney Software, you’ll notice the output project comes with a
SQLExecuteRaiseOnError method. What this method does is run the SQL, check for errors, and raises an exception if so. It’s a convenient, easy, and consistent way to check for and capture errors.
Thanks Tim, its nice to know you have got something right
Just because someone agrees with you does not mean you are right or wrong…
I create my own error classes. I have a base application exception class that is based on RuntimeException, a base database exception based on it and then specific database exception classes below that.
That way I can write try catch blocks to filter the errors I want to handle and which will bubble up.
Im happy with that approach as it avoids a lot of parsing error messages in the business classes.
I also log everything about the error: message, method name, stack and possibly the variable values as well.
Nice one James
Any chance you might share the code?