# That's not suppose to happen

Bug where the Predicate Reporter gets fired after the if statement get's called?

In the time I've programmed in Scratch (and Snap!), I don't think this is suppose to happen.

Can you share the project? Or at least a project with this specific code

(or, just get a script pic of the script)

That way I can import just the script directly without the need for you to share a project.

did you see the GIF above?

The gif is useful to show the behavior you're complaining about, but a script pic (right click on the script you're running and there's an option to download a png of it) contains the actual Snap! code as metadata, so we can drag your script pic into Snap! and it'll load the script and any procedures it needs to run. It's the coolest feature among many cool new features in Snap! 8.0.

Oh yes, I love this new feature. Do you think you'll be able to make it of full project/sprites with the scripts pic?

If you get a scripts pic of all the scripts in a sprite (right-click the editor background), it'll include the whole sprite in the image.

No? I already tried this and nothing happened.

The image is of the scripts, but the metadata contains all the properties of the sprite, I believe.

yup, that's what I'm saying.

Also, I found out that if the script doesn't import when you drag the image from the forum to snap, then you can just click the image to bring up the full size image (or at least the original image). That one can be dragged into snap, no problem.

Wow, I didn't know that! Cool!

well here's the script pic of what i'm talking about (there are also some instructions, neat!):

You're using your own version of TRY that doesn't provide an error handler.

Also, I'm not sure I'm reading your mind correctly, but it looks as if you are confused about the difference between a predicate (such as CONTAINS) reporting False and an error, which means that your program does something wrong and Snap! stops running it.

You are not throwing an error anywhere.
I dont see
[scratchblocks]
(js function\{[throw new Error()]\}::operators)
[/scratchblocks]

edit:lemme see what your error block consists of

No, what I mean is I try to throw an error and Snap! goes back to the try block and reports false, The weird thing is, it doesn't report anything/nor does it throw an error. (also the try block is taken straight from cameron8299's Object Creation Project.

The try block worked it Snap 7.3.1, but in Snap 8 the block doesn't seem to work.

I think what's happening is this:

The input to your TRY is type Any (Unevaluated). So when you call it with jjjj as input, Snap! basically wraps a ring around the jjjj, and then when you use that as input to CALL it basically removes the ring and reports jjjj. This is a perfectly good value, so TRY reports True.

It sound like you think TRY [JJJJ] will error, but it won't.

Am I misunderstanding?

I forgot to say that this is in a command ring:

This is the actual thing.

Full custom reporter block definition called "new Object":

What the try block is doing is trying to see if the variable prop is specified. If it is, check to see if it exists in a list called self.
If it doesn't throw an error saying "Property specified parameter does not exist on object."
The weird thing is, when I try doing:

I get:

Even though, it's supposed to throw an error. I clicked the "Visible stepping" button and debugged and I saw this (look very closely at the end of the GIF):

The try block was already evaluated, so why did Snap! go back and evaluate the catch statement in the try block? That's my question.

Thats how try catch work,it catches errors

LOOK AT THE MAIN POST
the try block is not supposed to run twice.

Well for one thing I think that call to ERROR is meant to be in an ELSE slot.

From the magic of reading the Snap! source code, I have found the reason. And it's a bug.

The try catch block is:

But my TRY block that tests if a variable exists is this:

So, the report block prevents the from running in the block.

The ONLY block that gets executed is the

block. The report <true/false> stops the err_reset from running from what I could see
(by using this handy feature called "single stepping")

Except, that's not what I saw in the source code:

Process.prototype.tryCatch = function (action, exception, errVarName) {
var next = this.context.continuation();

this.handleError = function(error) {
this.resetErrorHandling();
if (exception.expression instanceof CommandBlockMorph) {
exception.expression = exception.expression.blockSequence();
}
exception.pc = 0;