Re: and then... (a curiosity)

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

stefan-lucks@see-the.signature writes:
> > This is not funny. This one kills the idea, unless you forcefully convert
> > all exceptions into Constraint_Error, when a non-Boolean value is converted
> > to Boolean.
> 
> If I would actually propose something like that, I would probably propose 
> to raise Program_Error if the exceptions aren't all the same. 

If you have a situation where all operands are evaluated, then the exceptions
raised should only be those from the operand expressions themselves under
normal language rules: Constraint_Error if appropriate, whatever explicit
exception a function raises, etc.

To do anything else gives way to madness. If nothing else, it would be quite
difficult to determine the root cause of an exception, and examining source
code would not give obvious reasons.

The only way out is to have partial evaluation of boolean expressions, so that
you can have guard operands *and* consistent exception rules. But Ada already
has that with "and then" and "or else", so consistently use that if you wish.

The reasons of having "and" and "or" evaluate both operands is a least
consistent and logical according to Ada rules, especially given that they are
semantically function calls.

It's just that for me, if I see a boolean expression, I am by instinct
evaluating the boolean logic, not seeing the side effect of evaluating all
operands. If that needs to be stressed, i.e., is an explicit requirement, I
prefer the code to more clearly spell out that required evaluation, and leave
the boolean combination of the results as a separate step.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.