Since commands do not return anything how should my command block signal a failure e.g. when doing some network IO? The iteration library has a catch / throw but it seems the thrown tag has to be lexically visible at the throw. I did not find it mentioned in the user manual.
The "Catch errors" library has an ERROR block you can use to give an error message.
Thank you!
Did you know handling errors will be the subject of Jens's next talk? (He has announced it at his YouTube channel and I thought you might be interested.)
I hope his solution includes the ability to PAUSE ALL on an error, and then examine all the local variables of all the running blocks. (I know we can build that with the Catch Errors library, but it should happen without you having to plan ahead.)
This is about explaining existing features (or the lack thereof), not speculating about new ones. I guess this video shouldn't have been public, that was an accident, it's meant as an internal introduction to the other seminar participants I'll be meeting next week. The "bad ideas" I'm referring to have to do with avoiding error messages as much as possible, starting with syntax errors, and also most other ones (out-of-bounds, type mismatches etc.), by either replacing them with noops or by applying polymorphic behavior to them, with very few carefully chosen exceptions, and how to handle such exceptions (e.g. translate them to the user's spoken language, only halt the process in which they occur, integrate tools for stepping, tracing and inspecting into the IDE etc. etc.). It's a report, not a proposal. The guiding principles behind many parts of the design are §§ 133, 157, 1922, 1937 BGB (the German civil law code, sections on how to interpret declarations of intent among living or deceased parties).
I hope you record this talk! Because I think I disagree with that stance.
Scratch had great success with the idea of avoiding syntax errors by not letting you make the error in the first place. That works really well, because the user isn't left in ignorance of the syntax rule; they notice that Scratch didn't let them drop that block there.
I'm less convinced about bounds errors and domain errors. I hate that Scratch treats any non-number in a numeric context as zero, instead of reporting an error. I don't like that Snap! reports NaN as the result of the numeric operation, because that lets the computation continue, with what certainly wasn't the user's intention. NaN is for doing arithmetic on numbers and getting a result that isn't a number. And even then, I think our users would be better off with an error message when they divide by zero. NaN as a pseudo-number is meant for the half-dozen people on Earth who actually understand floating point computation to be able to express computations that end up with a truly numeric result despite a NaN intermediate value.
And I really, really don't like that the empty string and zero are more or less interchangeable in Snap!.
I do agree with
but you always yell at me when I complain about messages like
TypeError:
name.indexOf is not a function
which @scratchmodification got from the text costumes library when trying to give a costume a numeric name.
(By the way, 
works; you have to use the number as a number, as in 
, to get the error message. I think this is a failure of the "applying polymorphic behavior to them" idea.)
As for
I would argue that a better idea is to pause all on an error.
But I'm very interested to hear your arguments on these questions!
I'd like to hear more (as both non-math and non-CS person; having background in sociology and a bit of programming) about the inspiration (and guiding principles), found in the civil law code paragraphs you referred to.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.