Re: catch replacing useful errorInfo

On Aug 30, 6:23 am, cla...@xxxxxxxxx (Cameron Laird) wrote:
More soberly, yes, Larry: I've been threatening to write
a book on the subject of error-handling, and one of its
themes would be that, as you describe, developers have a
responsibility to code for many of the anticipated condi-
tions that otherwise manifest as "errors".

And if you handle before an error actually occurs, then catch can be
reduced to the purpose of protecting shared resources from exceptional
conditions. The point about errors is that the program is already not
doing the intended job, it is best to stop at that point and let
everyone know. An error log going to stderr can record the gory
details, but the user needs to know at least the fact that the
application has had an application error, different from an error
caused by the user due to bad data or some other easily corrected
condition.

Catching exceptional errors is also one of the last things to be done.
The reason is that during development you need to get as much error
tracing information as possible and also get very comfortable with how
you are going to use catch for your benefit and for the user's
benefit. It is also possible that you will cover up a bug in a package
you are just using, so delay use until code matures a little.

.

Quantcast