Re: onerror (was Re: some input on sieve-00)

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> On Mon, 28 Apr 1997, Steve Hole wrote:
> > On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter <jack@xxxxxxxxxxxxxx>
> > wrote:
> > > Personally, I would like to see an 'onerror' command that would allow you
> > > to try and trap an error.  This was actually a nice feature on one of
> > > the basics I used in grade school many years ago, as there were some cases
> > > where it came in useful.
> >
> > Sounds like a good idea.

> I'm opposed to an "onerror" command in the base spec.  It's very complex
> and adds very little functionality.

I agree. If "onerror" is to be added there has to be a class of errors
which are:

(1) Aren't purely syntax-related. (You cannot tell what an onerror command is
    supposed to do in the presence of syntax errors.)

(2) Are the result of some anomalous runtime condition. (Anything else should
    have been caught sooner, preferably at the time the rules were submitted.)

(3) Are something something you actually want users to be able to handle.
    (Something like a "cannot submit message because no disk space is
    available" isn't something I want users to be able to catch -- I want to
    deal with it myself.)

I believe that the class of errors that meet all three of these criteria is
empty in the language defined thus far. If anyone has a counterexample I'd
like to hear what it is.

				Ned