The Power of None

1

• The Power of None
• Andrei Alexandrescu
• Petru Marginean

2
Agenda

• Exceptions WTF?
• Why The Frenzy?
• Top 3 problems with exceptions
• Help from the type system
• The None type
• The LikelyltTgt type
• Conclusions

3
Exceptions teleology

• Most of us took them non-critically
• Heres the construct use it
• Whats a proper baseline?
• What were their design goals?
• What were their intended use cases?
• How do their semantics support the use cases?
• What were the consequences of their design?
• How to write code playing on their strengths?

4
Desiderata

• General learn once use many
• Minimize soft errors maximize hard errors
• Avoid metastable states
• Allow centralized handling
• Keep error handling out of most code
• Allow local handling
• Not all error handling can/should be centralized
• Transport an arbitrary amount of error info
• Exact little cost on the normal path
• Make correct code easy to write

5
Inventing Exceptions

• int atoi(const char s)
• Whats wrong with it?
• Returns zero on error
• 0, 0, 000 are all valid inputs
• Zero is a commonly-encountered value
• atoi is a surjection
• Distinguish valid from invalid input a posteriori
  is almost as hard as a priori!

6
Inventing Exceptions

• Four solutions for returning error information
• Set global state
• The errno approach
• Encode error information as a special returned
  value
• the out-of-band value approach
• Encode error information as a value of a distinct
  type
• the error code return approach
• Exceptions

7
errno

• General
• - Minimize soft errors
• Centralized handling
• Local handling
• Arbitrary amount of error info
• Little cost on the normal path
• - Make correct code easy to write
• Error handling entirely optional
• Threading issues

8
Special value

• - General (wont work with surjective functions)
• - Minimize soft errors
• - Centralized handling
• Local handling
• - Arbitrary amount of error info
• ? Little cost on the normal path
• - Make correct code easy to write
• Error handling often optional
• Error handling code intertwined with normal code

9
Value of separate type

• General
• ? Minimize soft errors
• - Centralized handling
• Local handling
• Arbitrary amount of error info
• Little cost on the normal path
• - Make correct code easy to write
• Error handling requires much extra code data
• E.g. strtol(const char s, const char e, int
  r)

10
Exceptions?

• 1. We want to pass arbitrary error info around
• class invalid_input
• intinvalid_input atoi(const char str)
• intinvalid_input r atoi(some_string)
• typeswitch (result)
• case int x
• case invalid_input err

11
Exceptions? (contd)

• 2. We want to allow centralized error handling
• Break the typeswitch gt covert return types!
• overtltintgtconvertltinvalid_inputgt atoi(const
  char)
• Local code should afford to ignore invalid_input
• gt A function has an overt return type plus one
  or more covert return types
• Q Where do the covert return values go?

12
Exceptions (contd)

• We also want centralized error handling
• Covert values must return to a caller upper in
  the dynamic invocation chain
• Only certain callers understand certain errors
• gt Covert returned types come together with
  covert execution paths!
• gt Callers plant return points collecting such
  types
• gt Type-based, first-match exception handling

13
Exceptions Aftermath

• General
• ? Minimize soft errors
• Centralized handling
• - Local handling
• Arbitrary amount of error info
• Little cost on the normal path
• ? Make correct code easy to write
• 1986 yes
• 1996 no
• 2006 maybe

14
Top 3 Issues with Exceptions

• Metastable states
• User must ensure transactional semantics
• Destructors
• ScopeGuard
• Make local error handling unduly hard/asymmetric
• By-value semantics prevent library approaches
• Hard to analyze
• By human and by machine

15
Today

• Local handling
• Minimize soft errors
• Make correct code easier to write

16
The None type

• Returned by a function with no overt returns
• None Abort()
• None Exit(int code)
• None LoopForever()
• Properties
• Can be substituted for any type
• The bottom of the type hierarchy
• Destructor throws
• Noncopyable

17
Creating None

• class None
• None(const char info ) info_(info)
• template ltclass Tgt
• operator T() const
• throw runtime_error(info_)
• Conversion to reference allows lvalues and rvalues

18
Using None

• int FindSomethingIKnowIsThere(const T obj)
• for (int i 0 i ! size i)
• if (obj collectioni) return i
• return None()
• Returning None is like throw, but more
  type-versatile
• Not very exciting so far

19
LikelyltTgt

• Idea We want to express an overt type plus a
  covert type
• Normal case value of overt type is there
• Erroneous case a value of type None is there
• Unify local and central error handling
• Likelyltintgt atoi(const char )
• Wanna local? Check against None()
• Wanna centralized? Use LikelyltTgt as youd use a T

20
Creating LikelyltTgt

• template ltclass Tgt struct Likely
• Likely(const None none)
• Likely(const T v)
• Likely() // throws if not compared against
  None
• operator T() const
• template ltclass Ugt
• friend bool operator(const LikelyltUgt lhs,
  const None)
• private
• T value_
• None nonValue_

21
Using LikelyltTgt Centralized

• Centralized error handling convert LikelyltTgt to
  T liberally
• Exception is thrown if the object is a dud
• Code is similar to that with entirely covert
  returns
• int x atoi(some_string)
• Separate normal path from error path
• Just like with exceptions

22
Using LikelyltTgt Local

• Localized error handling
• Likelyltintgt r atoi(some_string)
• if (r None())
• local error handling
• Just like good ol error handling with special
  values
• Exacts a tad more cost
• Can specialize to alleviate cost
• No more issues with surjections gt general!

23
Using LikelyltTgt Ignoramus

• If
• A LikelyltTgt object is a dud
• Nobody attempts to dereference it
• Nobody checks it against None
• Then
• LikelyltTgts destructor throws an exception
• Keeps error handling required
• Avoids metastable states
• Easy to supress IGNORE_ERROR(atoi(str))

24
Conclusions

• Exceptions design address a complicated web of
  desiderata
• Fails to provide complete solution
• Better than others
• Requires a shift in code writing style
• Possible to make local and central error handling
  interchangeable
• Type system can help
• Keeps error handling required
• Avoid asymmetry