When you remove a sound from the sound tab, Scratch just ignores it. Snap instead makes the script red, and stops running the project.
Scratch behavior reveals very useful when you want to load a project in the Snap cloud that, limiting the project size to 10MB, doesn't allow to load projects with many sounds. You can quickly remove all sounds from the sound tab, but removing all the sound blocks is a too long operation.
Hi Stefano,
Only some more comments about what you are requesting...
- "play sound (name)" block does not stop running the project. It does nothing if the sound does not exist. I think this is fine for you.
- "play sound (name) until done" yes! It stops the script (not the project!) because we can have its ending response. Also "play sound (name) at (frequency) hz" block stops the script too (it can read sound data to do its job). I guess you are requesting for changing this behavior (about these two blocks). I'm not sure if it is right.
- Aside, I think "(property) of sound (name)" reporter block must stop scripts, right?
Joan
That works. But the projects of my students that I'm importing use both "play sound" and "play sound until done". Those last blocks should be all replaced by the "play sound" one
Right.
I suppose so. Or it could return an empty value.
Ok
I only want to point the details of your request.
In my opinion, if some change is implemented, we must check all the primitives together (no only these sound blocks). What's happening when we tell/ask to a missing sprite, when switch to a no costume, play no songs, use no variables...
My first approach is:
- Ok to do nothing (no error, changing our current behavior ) when we play a sound that not exists.
- Ok to make errors (as current behavior) when we want to report something of a missing sound.
Reporting empty values can be confusing (in some cases is the same as 0, because we have no types) and no returning nothing is bad.
Extra note. I see now "ask" block is not returning when we ask to a missing sprite. It is bad and causes a unfinished process when we use that reporter as an input for other blocks.
Joan
I like a lot languages with "soft" behaviors, returning default values (maybe not the wanted ones) instead of raising errors. I know the errors get more difficult to be spotted. So, your proposed solution is fine too to me.
I like the Scheme approach in which any value other than Boolean False counts as true in conditionals. So non-predicate functions can return False as a sort of soft error flag, and you can use the result directly in an IF/ELSE as a poor man's exception handler.
This would be an incompatible change to Snap!, but not a bad one, I think, because the current behavior is not to accept non-Booleans in conditionals. It would just, as you say, mask errors. What really stands in the way is that 0, which isn't False and should therefore take the true branch of an IF, counts as false in Javascript, hence in Snap!.
On the third hand, since we're moving toward APL capabilities, I may learn to love 0 being false, which APL puts to good use.
And I expected
to report 3 not true.
One can run the play sound until done inside of a safely try (from the standard library)
One can define a "safe play sound ... until done" block that packages this up nicely.
That would solve the problem if removing a sound must not raise an error.
guess I could add a new custom PLAY SOUND UNTIL DONE block and parse the XML project file to replace the standard block with the custom one.
I wonder if the way Snap! treats built-in blocks is a good policy. When 'map' became built-in I was confused to see two 'map' blocks that look and behave the same (other than speed and debugging).
I like the possibility to have a custom block with the exact same signature of a standard block.
In this way I can hide the standard block, add the custom blocks with the same signature, and then show my students how "standard" blocks work inside. And they discover that -out of more than 100 scratch-like blocks- no more than about 20 blocks are really needed when you learn how to use variables (note: my students develop very complex projects without using any variable).