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.


-- Barry