Subject: Re: some input on sieve-00

From: Steve Hole <[email-masked]>
Date: Mon, 28 Apr 1997 17:43:37 -0600 (MDT)

On Sat, 26 Apr 1997 13:20:36 -0400 Jack De Winter <[email-masked]> 
wrote:

> >6. Errors in Processing a Script
> >
> >The stipulation that implementations SHOULD NOT try to recover from a
> >script with errors is a problem for me.  Aborting within an 'if' clause
> >makes sense to me, but to totally stop filtering if any error is encountered
> >is the wrong thing to do.  I would venture a guess that most users would
> >consider this a very bad characteristic of the mechanism.
> 
> 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 would like to see an optimization made to the grammar.  In the elements
> >of an if-clause condition that use a list as an argument, I would like to
> >see the ability to not necessarily have the parens for single-item lists.
> >It might also be nice for users to not have to use quotes around words that
> >don't need them.
> 
> I agree on the single item lists, but not on the quotes.  The UA can
> put them in, and it makes parsing a lot simpler.

Exactly.

Wow - Jack and I agree on TWO things at once.   A truly auspicious day.  
Makes me nervous like when I write 500 lines of code and get no syntax 
errors on the first compile :-).

Cheers.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6

---

From: Chris Newman <[email-masked]>
Date: Tue, 29 Apr 1997 14:54:10 -0700 (PDT)

> > the basics I used in grade school many years ago, as there were some cases

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 Apr 1997 18:58:50 -0700 (PDT)

> 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