In article <✉forums.inprise.com> Raoul De Kezel <✉hotmail.com> wrote:
> In article <✉4ax.com>, ✉eircom.net says... > > I'm far from certain that exceptions are the correct method for handling > > database "errors", because database "errors" aren't really errors; they > > are very much run-of-the-mill conditions that happen day-in day-out. > > Precisely. They are exceptions to the standard behavior, and it > therefore makes sense to report them with exceptions.
No, their not. A file-system error is an exception to run-of-the-mill coding; you don't expect your .SaveToStream method to have to handle a file-system running out of space.
On the other hand, a method/function/procedure that saved something to a database and didn't take care about key violations etc. and thus left the database in an invalid state, would be a pretty bad piece of code.
> It is somewhat common these days to read that exceptions should > be used to report errors and only errors. This statement goes > against every theory of exceptions. It is also usually void of > any content because the precise meaning of "error" is unspecified.
"Error" isn't a word with an exact defined meaning; one man's error is another man's event.
"Errors" with databases are to be expected, and must be dealt with. I honestly don't think exceptions are the correct mechanism for dealing with these events; for one thing, catching a raised exception eats up CPU cycles far more than a conditional check.