Question

Background

I’m writing a web application and I have a stored procedure which inserts some data into a table. As a programmer I am suspect of IO so my gut tells me I need to do some exception handling in case this write fails.

The intended effect of the error handling within the stored procedure would be to set a flag to be consumed by the DAL (in PHP) which would alert the user that something has broken as well as sending the details to the admin.

Questions

What is the best strategy with respect to handling errors at this level given that I want any error generated to trigger this handling?

MySQL error codes and SQLSTATE values are good for identifying specific errors and don’t appear to be what I’m looking for. SQLEXCEPTION seams to be a broader error handling mechanism that may suit my needs but I wonder if this is somewhat analogous to catching Exception in C# with respect to the potential to catch things that I really shouldn’t

Am I looking at this from COMPLETELY the wrong angle? I’m currently of the view that keeping as much of the data logic in the database is a good idea, so handling database errors in the database seams natural but I’m open to suggestion.

Answer 1

Am I looking at this from COMPLETELY the wrong angle?

Yes. If you can’t trust your database to handle I/O errors, you’re missing the point of using a database.

The usual drill is to do as little as possible in your stored procedures. Your PHP program will get errors and exceptions and that’s what you wanted to happen. Since PHP will get the exceptions, what are you worrying about? Just let them pop out of your stored procedure.

Your PHP will have to “alert the user that something has broken”.

If you want to somehow “wrap” all your stored procedure in some kind of error logging, do this in PHP. Don’t mess with over-writing your stored procedures. Don’t worry about I/O errors. You have a database to handle that.