Database error reporting approach

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.

Does this seem a reasonable approach to manage error reporting to the end user, or is there a better method ?

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.

Does this seem a reasonable approach to manage error reporting to the end user, or is there a better method ?

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.

@Stephen T 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.

I’m 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.