Control Flow and Error Handling

Expressions

  • Blocks have value

  • Operator precedence table is page 141-142 of text. 18 levels. Left associativity. Left-to-right evaluation?

  • Conversion is mostly explicit through as. Only conversions that are safe work

  • Reference magic happens

    • Auto dereference in certain situations as discussed earlier
    • Auto reference conversions in certain situations, e.g. String, Vec, Box

Expressions and Control Flow

  • In Rust, some of what we would normally do with control flow is done with simple expressions. This is part of Rust's functional-language heritage

    • if is an expression type
    • "method" chaining is a standard mechanism

"Method" Chaining

Explicit Control Flow

  • if-else

  • match

  • while

  • if let, while let

  • for and iterators

Error Handling: Panic

  • panic! is that thing that should never happen in a proper program

  • Panic is a true exception: will be "unwound" by default, can be caught (!) but normally shouldn't be

  • Why unwinding? Because drops do cleanup by default, so leave the world safe as possible before exiting

Error Handling: Abort

  • Can call std::process::abort() for non-unwinding immediate stop that will cause a core dump (if enabled)

  • Can debug the result with gdb

  • Useful for weird debugging situations

Error Handling: Result

  • Result is simple enum type with two value-carrying options: Ok and Err

  • "Normal" way to handle errors returned by standard library

  • Err takes a value implementing std::error::Error; there are many kinds of these in the standard library

  • You can add your own error type

Error Handling: Option

  • The Option type is often used for returning certain kinds of error

  • Style question here: best practice is probably to use Option for situations where nothing has really "failed" per se, but the semantics get mooted a lot

An Example: Pop On Empty Stack

  • Could abort(): pretty drastic

  • Could panic!(): still pretty drastic, but at least proportionate

  • Could return a Result with a custom error indicating popping an empty stack. Probably right if intent is for pop() to be a "partial function"

  • Could return an Option. This effectively indicates that popping an empty stack is not to be regarded as an error. Probably right if intent is for pop() to be a total function

Last modified: Tuesday, 17 April 2018, 6:07 PM