Re: catch replacing useful errorInfo

On Aug 30, 3:38 pm, Alan Anderson <arand...@xxxxxxxxxxxxx> wrote:
"tom.rmadilo" <tom.rmad...@xxxxxxxxx> wrote:
And if you handle before an error actually occurs, then catch can be
reduced to the purpose of protecting shared resources from exceptional
conditions.

How can you handle an error before it happens? I also don't understand
why handling exceptional conditions for shared resources would be any
different from non-shared ones.


Below I give an example, but basically as the developer you know, or
will know, the requirements of the following code. Maybe you are
taking an integer from the user. But the user could supply a non-
integer. If you check for this prior to using it in code which expects
an integer, this is handling the error as a client error, before it
becomes an application error. Catch is not needed, the client can get
a useful message, and there is no need to think about undoing a half
done job.

Shared resources are very different from non-shared. If a thread opens
a temporary file to write some data, it usually doesn't matter if the
process aborts, or the thread aborts, because another thread doing a
similar task will open another temporary file, completely unaffected
by any other temp file. However, if you use a file lock to provide
shared access to a file, you have to release the lock after you are
finished. Errors here could end up skipping the code which releases
the lock. Now the next thread is stuck, maybe even a restarted
application will fail until the lock is removed. This is just basic
coverage of shared resources, more robust applications could have
additional points for recovery.

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.

Not so. Sometimes the job involves attempting something that has a
significant chance of encountering an error, such as making a connection
to a network service to get a status report. A failure to connect can
be a valid result. The problem could be temporary, and is not fatal to
the program, which can try again later.

Maybe you are using the wrong programming model for this, you
shouldn't be required to handle errors for expected conditions. It's
not like network programming is a new thing. But you seem to be
looking for a point of disagreement, how much code is involved in
making a network connection? I've been pretty explicit that catch
should enclose the smallest amount of code possible, not that it
shouldn't be used. I've also said that the developer is the final
decision maker.

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.

What do you mean by "application error"? That sounds like something
very different from what I usually see [catch] used for.

An application error is due to the operation of the application
itself, not due to client errors.
The original example for this thread was:

catch {incr i "oops"}

This is an application (programming) error. But

catch {incr i $num}

Could also lead to an application error. Did we check that $num is an
integer? If not, we have an application error, which can be converted
to a client error by checking if $num is an integer. Then we can
remove the catch.


Catching exceptional errors is also one of the last things to be done.

Are you saying that it usually ends up that way, or that it *should* be
that way? My most robust programs come about when I take the time to
practice paranoid programming and write code to catch errors early in
the development cycle.


Errors happen at runtime, not during the development cycle. Error
catching code is put in last because 'catch' covers up the source of
an error. If you are developing, running developing code inside a
catch, how can you locate the error? You have to distinguish between
coding errors, data input errors (client) and actual errors which mean
that the code cannot function as intended. If you don't distinguish
these general causes of an error, good luck.

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.

What you're saying is totally at odds to how I think of it. It's so
different that I have to wonder if your concept of an error is not the
same as mine. Or maybe you just have a mistaken idea of what [catch]
does and how to use it.

I'm not trying to persuade anyone. An error is something which
triggers catch to return something other than TCL_OK (0). I have
provided an example and complete explanation of how and when I use
catch. Why not provide an example of your own so I know how you use it?

.