Catching hardware / arithmetics errors

Hello,

is it worth having a discussion of making things like bus / address errors / arithmetic overflows / zero divisions, etc, etc "catchable" as if they were throwing operations?

func foo(x: UInt8, y: Int) {
try { // a new usage for try: within this block all try's are implicit
x + 1 // EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
1/y // Fatal error: Division by zero
} catch {
print(error)
// prints:
// FatalError: arithmetic overflow
// Fatal error: Division by zero
}
}

2 Likes

Slightly related:

somewhat "tangentially" :slight_smile:. i wasn't talking about floating point.

The combination of these changes - implicit conversion of previously fatal conditions to throwing and implicit try - bring out undefined behavior for any functions called within the block.

If these functions have incorrect behavior (including do to your input), those functions will likely not be defined to treat that as a recoverable error, and result in components of the system operating with a known-to-be-inconsistent state.

At the same time, the way incorrect usage of an API can change based on build settings - what may be a fatal arithmetic overflow in a development build may not be in a release build. Code that expects an error on bad input may now instead proceed with bad state.

Terms of Service

Privacy Policy

Cookie Policy