We've had some interest in generic "panics" that we don't require declaring a function as bubbly to use. We'd likely disallow catching such panics in Temper code, although some backends would be able to handle them. We'd need some way to distinguish them from other errors. Here are some possible representations in some backends (current or future).
Here, Bubble just means an exceptional result that we declare and handle. Some of these have clearer distinctions than others (and see related table here):
Language
Bubble
Panic
C
error code as pointer arg, error code as return with result as pointer arg
And here are places in temper-core that currently bubble, where redesign is often another option but not listed here in alternatives:
Function
Conditions
Alternatives
as
bad cast
Deque::removeFirst
empty this
panic, null??? (and maybe ok even if nullable T because could check beforehand if wanted)
Float64::toInt
bad this
null??? see also Float64::toIntUnsafe
Generator::next
whenever the generator function bubbles
GeneratorFnWrapper::generatorFn
user defined
GeneratorFnWrapper::next
whenever the generator function bubbles
Int::toFloat64
bad this
null??? see also Int::toFloat64Unsafe
List::get
bad index
panic
ListBuilder::add
bad index
panic
ListBuilder::addAll
bad index
panic
ListBuilder::removeLast
empty this
panic
Listed::get
bad index
panic
Listed::mapDropping::transform
user defined
null
Listed::reduce
empty this
panic???
MapBuilder::remove
missing key
boolean???
Mapped::get
missing key
null??? expensive to precheck for panic
SafeGenerator::next
whenever the generator function bubbles
String::fromCodePoint
bad arg value
null
String::fromCodePoints
bad arg value
null
String::get
bad index
panic
String::toFloat64
bad this
null
String::toInt
bad this or bad radix
null for bad this, panic for bad radix
Current exception types by backend, where these don't need listed:
JS, because we currently just use Error for everything
Lua, because we currently only apply separate messages
Rust, because errors and panics are different
Star ("*") below means that we might consider panicking for the case in question. And for some backends, we sometimes throw generic exceptions but not always.
We've had some interest in generic "panics" that we don't require declaring a function as bubbly to use. We'd likely disallow catching such panics in Temper code, although some backends would be able to handle them. We'd need some way to distinguish them from other errors. Here are some possible representations in some backends (current or future).
Here, Bubble just means an exceptional result that we declare and handle. Some of these have clearer distinctions than others (and see related table here):
And here are places in temper-core that currently bubble, where redesign is often another option but not listed here in alternatives:
Current exception types by backend, where these don't need listed:
Star ("*") below means that we might consider panicking for the case in question. And for some backends, we sometimes throw generic exceptions but not always.