Re: and then... (a curiosity)

[stefan-lucks@see-the.signature]

On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote:

> On Thu, 4 Sep 2008,  wrote:
> > So if I understand you correctly this time, the raising (or not) of an 
> > exception for "if Y/X<000" should in your view depend on the context where 
> > it is used: [...]
> 
> No, you misread me again. If you had read some earlier posts from me in 
> this thread, what I am trying to express is that "and" should better do 
> what "and then" actually does. That is it, so simple!

To be precise, here is a cut-and-paste from what I wrote in another 
posting:

1. If the A- or the B-part in "if A and B" raises an exception, but the
   other part is false, the "right thing" (TM) to do would be to transfer
   control to the else clause (or below "end if", when there is no else).
   The intermediate result can be viewed as a three-valued logic
   expression, but the final outcome of the Boolean expression must be
   Boolean, of course.

2. If both raise A and B an exception, of if one raises an exception and
   the other one is true, an exception is propagated. 

3. I would be willing to pragmatically sacrifice mathematical purity for a
   shortcut rule: If A is false, the expression is false, whatever B does.
   If A raises an exception, of if A is true and B raises an exception,
   the exception is propagated.

1. and 2. describe some "ideal" behaviour, but 3. describes what the one 
can realistically expect from the compiler. BTW, the compiler would not 
need to be that incredibly smart. If an exception is raised when 
evaluating a Boolean expression, the exception could be handled inernally, 
to finish evaluating the Boolean expression, and re-raised if neccessary. 

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------