On Fri, Oct 21, 2005 at 01:07:53PM -0700, Ned Freed wrote:
On Fri, Oct 21, 2005 at 10:44:20AM -0700, Ned Freed wrote:
On Thu, Oct 20, 2005 at 01:20:07PM -0400, Scott Hollenbeck wrote:
I did wonder about that wording; seems to me that the the script
as
a whole probably shouldn't fail, but the non-first vacation
action(s) should give an error. i.e. duplication vacation actions
should fail, not abort the entire script. (Not to mention that if
the script were to fail on the second "vacation" then there would
be
no need to say "or more".)
I think this is an absolutely terrible idea.
Which idea do you think is terrible? Multiple vacations causing a script
to fail, or simply reporting an error on a multiple vacation?
The idea that multiple vacation action errors should be silently ignored
until the first non-vacation action is taken.
Ah. But that's a third case. Why would the first non-vacation action
cause an error? The context was whether in:
vacation :handle x "something"; # A
vacation :handle x "something"; # B
whether executing B causes the script to fail, or whether the script
continues past B (suppressing the execution of the B action, whether
noting an error or not).
It should cause the script to fail.
A later non-vacation action (in this case,
"fileinto") shouldn't cause an error whether there is one vacation
statement or two. So the example is still confusing to me.
Particularly the comment about the success of the test mattering, rather
than the multiple vacation actions being executed.
Hmm, going back again... perhaps you were reading my "non-first
vacation" as "non-vacation" ?
Yes.
There is certainly precedent for suppressing duplicate vacation
actions.
I disagree. AFAIK we have no other situation where repeating an action is
supposed to be an error but repeating an identical action doesn't produce an
error. The obvious case where repeating an action is an error is reject, and
it's an error even if the second reject is identical.
The base spec says (at least the way I read it, and thus the
way I implemented it) that multiple attempts to file into a folder will
be silently suppressed.
The cases are not really comparable. Multiple fileintos are not an automatic
error. The only time multiple fileintos would produce an error is when they
exceed the implementation's limit on fileintos, and the spec is silent (as it
should be) on whether or not such a limit counts identical fileinto separately
or not.
VIolations of the least
astonishment principle abound. Consider:
vacation whatever1;
vacation whatever2;
if test {fileinto blah;}
If the test fails the script appears to work, sending one vacation
response
but not the other. But if the test succeeds the script now fails for
reasons
having nothing to do with the test. Such a gotcha can remain hidden
indefinitely only to go off when you least expect it - a script
landmine.
I still don't get that. Probably it's me. When you invoke the
principle of least astonishment, I find that that is accomplished by
making the vacation action work in the same way as fileinto, for the
same reason.
Perhaps, but this consideration is trumped by the fact that sending multiple
vacation messages is a bad thing thing. Multiple fileintos, OTOH, make total
sense in a lot of cases.
And with duplicate vacation causing a failure, you get
that 'landmine' (which I would simply describe as a coding error) even
more with:
vacation whatever1;
if test { vacation whatever2; }
fileinto "blah";
Some issues can be avoided, others cannot. Deferring errors is something we can
avoid specifying. Unless we're willing to make all actions unconditionally
compatible with all others we cannot possibly get rid of all these cases.
Making something like:
reject "foo"
if test { fileinto "bar";}
work regardless of how the test turns out isn't worth eliminating the
restriction that reject isn't compatible with most other actions.
The minute you have failure cases that don't report when encountered and
instead wait for some other condition to arise before becoming an error
you've
got a mess on your hands.
I completely agree with that. What I don't understand is how it applies
to this particular point. (OTOH, unrelated to vacation, it could apply
in an implementation that defers actions.)
See above. I don't know what else I can say.
Ned