Catching hardware / arithmetics errors

[tera]

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
}
}

[Tino]

Slightly related:

Comparable and FloatingPoint types

Even if you could interact with them in Swift, that would give worse performance on every existing architecture; reading and modifying these registers is generally a "stop the world" serializing operation, while testing for NaN with comparison is just another floating-point operation. In a model where there were no "normal" floating-point operations, you could simply enable the invalid trap ("unmask the floating-point exception"), but you'd still need to toggle it at any call that could potent…

[tera]

@Tino

Slightly related:

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

[dwaite (David Waite)]

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.