In <emacs-28793-13516-48887-696940(_at_)nil(_dot_)andrew(_dot_)cmu(_dot_)edu>
TJS+(_at_)ANDREW(_dot_)CMU(_dot_)EDU writes:
From: "Stan Bailes" <stan(_at_)quadcap(_dot_)com>
Date: Mon, 26 Jan 1998 07:12:27 -0800
Though I can see it now: the first line of every Sieve script will be
require "support";
I oppose require unless it's metainformation for similar reasons to my
opposition to support. ;-)
(My basic problem is that I never want runtime errors. A script should be
verified at time of submission, and if it's unusable, it should be
refused, and never run. Require is taken out of the most recent draft to
stop runtime errors like
Though I'm ambiguous on "support"; you're GOING to encounter runtime errors
on occasion. From our simple rules implementation:
'IF subject contains "some string" FILE trash-folder'
(Which is a pretty common use of rules - I think you'll agree) you're going
to encounter situations where the user HAD a "trash-folder" when the rule
was defined, but has since removed it. So there has to be a (simple? or at
least consistent) means of reporting such errors. With multiple-access
protocols like IMAP, it's possible that the process defining the rules
wouldn't know about the change until a rule was executed.
Obviously that's not in the same league as an error parsing the script, but
the effect is near the same. A rule (maybe a critical one) is invalid. What
do we do? Given any "rule" whose action depends on a "parameter" - like a
folder name or some other mail-system attribute that can change - there's
always the chance that when it's actually "executed" that the action is not
valid. I don't have a good solution here, though I would hope that the new
syntax would allow the script-creator some means of controlling what happens
at run-time. Ignore; stop all rule processing; send an e-mail error report
and go on; etc. Either a global setting in the script or a per-line error
handling option perhaps -- with a CLEARLY defined default behaviour.
-Chris Bartram