Re: Signalling errors (was: Re: [Windows] Associate file extensions with a program)
> The same as above, but without
> else ErrNo = 0.
> In this case, 'ErrNo' never will be cleared, and it always holds the
> number of the last error that occured.
>
> I can see that implementation #1 is not a good idea, but what about
> implementation #2?
>
> Regards,
> Juergen
Just my chiming in... In my Die Roll script library, there are tons of
potential causes of errors (there's user input... :) ). I solved the problem
using the following scheme:
1/ There's a global error variable, which is 0 on success and has some other
value otherwise. Any value, including sequences of atoms, can be returned as
the result of normal operation, so that there's no reserved error return
value. This choice makes sense as success is unique and error has multiple
forms, and 0 looks like a good unique value.
Further, code like "if error then..." looks quite readable, for me at least.
2/ A global clearError() (not the real name) procedure is provided to clear
error conditions.
3/ If some error was reported and not cleared, that error is kept unmodified,
and no normal operation takes place. Main routine returns immediately.
4/When an error occurs, the routine in which that happened returns as soon it
can, and other routines in the calling path check for errors and return
without modifuing the status variable.
5/ A global flag errorMode is provided. If clear (default), invoking the main
routine clears error conditions automatically (this assumes the client xhecks
for error conditions iteslf). Otherwise, the client must clear errors using
the procedure of point 2/. The client dynamically xhooses and changes the
value of this flag.
This scheme makes code more complex, because of the number of "if error then
return <whatever> end if" lines, one after each subroutine call that may throw
an ... errm, set the global error status variable. But it is more robust and
allows safer use, I think. Of course, this architecture will not suit every
kind of program.
<sigh>An exception handler with resume abilities would make this much easier
to implement </sigh>
CChris
|
Not Categorized, Please Help
|
|
