From @finneyj :
Feels like we need a bit of a precedent on when we use fail-fast techniques like this and when we try to be tolerant and NOP etc to keep kids' code running... hmmm.....
If we go down the fail-fast route, maybe we should look at more specific panic codes, and make better use of DMESG
to provide feedback... thoughts?
The way I look at it, is that if we or some other C++ package writer makes a mistake, then it should be panic. Otherwise, we get issues that are difficult to debug. This includes situations when we run out of memory while allocating system resources, or we run out of component IDs. Maybe we can make this optional - i.e., have a macro PANIC(code, "message") that can be compiled to nothing.
If user supplies values out of range we should either ignore or clamp (i.e., IMHO analogWrite(1500) should be treated as analogWrite(1023)) - this is under assumption that it's easier to debug for the user if the code does nothing rather than crashes. This is especially true for stuff accessible from blocks.
This is in line with JavaScript semantics - i.e., undefined / 7 is NaN, some_array[100000] is undefined etc. One place where JavaScript throws is method call on null. But I don't think we want to deviate from JS semantics here.
The distinction between error in C++ and error in user code is of course up to a specific runtime, but I think it will be fairly clear in most cases.
CC @pelikhan @tballmsft @abchatra @MicrosoftSam @riknoll
From @finneyj :
The way I look at it, is that if we or some other C++ package writer makes a mistake, then it should be panic. Otherwise, we get issues that are difficult to debug. This includes situations when we run out of memory while allocating system resources, or we run out of component IDs. Maybe we can make this optional - i.e., have a macro
PANIC(code, "message")that can be compiled to nothing.If user supplies values out of range we should either ignore or clamp (i.e., IMHO
analogWrite(1500)should be treated asanalogWrite(1023)) - this is under assumption that it's easier to debug for the user if the code does nothing rather than crashes. This is especially true for stuff accessible from blocks.This is in line with JavaScript semantics - i.e.,
undefined / 7isNaN,some_array[100000]isundefinedetc. One place where JavaScript throws is method call onnull. But I don't think we want to deviate from JS semantics here.The distinction between error in C++ and error in user code is of course up to a specific runtime, but I think it will be fairly clear in most cases.
CC @pelikhan @tballmsft @abchatra @MicrosoftSam @riknoll