Programming generally requires Boolean logic, so every practical language supports it with
not, and other such operators. In almost all languages, these operators receive their Boolean inputs as ordinary values.
(if (and a b) c d) evaluates
a, and the resulting value determines whether to evaluate
b, and so on. This is all so obvious and familiar that it's hard to imagine it could be otherwise.
Icon does it differently. Icon expressions (and functions) have two continuations: they can succeed and produce a value, just like expressions in a thousand other languages, or they can fail. This feature has many uses, and one of them is to represent Booleans: Icon encodes them not in values but in success or failure. Its
if operator doesn't look at the value returned by the conditional expression — it only looks at whether it succeeds or fails. Similarly, its
or operator (called
|) evaluates its second argument only if the first fails. In Icon, Booleans aren't values.
Few languages have Icon's success/failure semantics, but it doesn't take exotic semantics to encode Booleans this way. Any language with exceptions can do something similar: returning normally means true, and throwing an exception means false. Most languages with good support for exceptions use them extensively in their standard libraries, so functions that return exception Booleans are already common.
It's not often recognized, though, that one can define operators on these Booleans. I briefly thought Perl 6 did, based on a misunderstanding of its
orelse operators, but it turns out they operate on defined vs. undefined values, not exceptions. (Perl, true to form, has several ways to represent booleans, one of which is defined/undefined.) However, there are a few exception-Boolean operators in existing languages, even if they're not usually described that way:
beginis the exception equivalent of
and: it evaluates each subform only if the previous ones returned normally.
- Many languages have an
(assert expression)operator, which converts a value Boolean into a exception Boolean.
- Common Lisp's
(ignore-errors expression t)converts an exception Boolean into a value Boolean, returning
nilon error and
totherwise. (However, it only handles
errors, not all
- Some test frameworks have a
(must-fail expression)form, which throws an exception iff the expression doesn't. This is the exception-Boolean equivalent of
Given macros and an exception-handling construct, you can easily build others, such as
(defmacro succeeds (form) "Convert an exception Boolean to a value Boolean: return true if this form returns normally, or false if it signals a SERIOUS-CONDITION." `(handler-case (progn ,form t) (serious-condition () nil))) (defmacro eif (test then &optional else) "Exception IF: THEN if TEST returns normally, otherwise ELSE." `(if (succeeds ,test) ,then ,else)) (defmacro eor (&rest forms) "Like OR, but treating normal return as true and SERIOUS-CONDITION as false. Perhaps surprisingly, (EOR) signals an exception, since that's its identity." (cond ((null forms) `(error "No alternatives in EOR.")) ((null (cdr forms)) (car forms)) (t `(handler-case ,(car forms) (serious-condition () (eor ,@(cdr forms)))))))
These operators may be a fun exercise, but are they of any practical use?
There is a tension in the design of functions that might fail in normal operation — those that depend on the cooperation of the environment, like opening a file or making a TCP connection, and even those that return something that may or may not exist, like hashtable lookup. Such functions face an awkward choice between indicating failure by their return value (e.g. returning
nil, or a
Maybe) or throwing an exception. A special return value is most convenient for callers who want to handle failure, because they can easily detect it with ordinary operators. But it often forces those who can't handle the failure to explicitly check for it anyway. An exception, on the other hand, is perfect for callers who can't handle failure and just want it to propagate up automatically, but awkward for those who can handle it, since in most languages it's much easier to check for
nil than to catch an exception. So functions are forced to choose how they report failure based on guesses about how often their callers will want to handle it.
Exception logic might ameliorate this. If you can handle exceptions as easily as return values, then exceptions are no longer at an expressive disadvantage. This means you can use them more consistently: virtually any function that might fail can indicate it with an exception — even the commonly tentative ones like dictionary lookup. So exception operators are interesting not for their own sake, but because they may allow other parts of a language to be more consistent.
Like all error handling features, this is hard to experiment with in pseudocode, because it's so easy to ignore error behaviour. It's also hard to experiment with in a real language, because its value depends on changing so many library functions. So I wouldn't be surprised if I've overlooked some common case where exceptions are still inconvenient. But this sort of thing is worth looking into, because it could make libraries simpler and more consistent.