# Workarounds for blocks Snap doesn't have (Part 1)

You can just use

I didn't know that the point towards supported list input in snap. Cool.

Yeah we're trying to promote the idea of a point as a semi-primitive semi-abstract data type, so you can have lists of points and so on.

(PS Looks even cooler if you keep the pen up while collecting the vertices.)

Ooooh! That's a really neat project, Brian!!

Thanks!

The catch block in the Iteration, composition library does not resume from the throw block when returned to. I have programmed that feature.

It does for me. Can you send an example that fails using the library version? Thanks.

Number of sprites:

There's probably a more efficient/neater way to do this, but I'm new to JS, so this is what I got.

psst, there is string.includes(substring)

Actually I could have just done "ask stage for my other sprites".

Oh I get it; I thought you were reporting a bug, but you just want (and programmed) different behavior.

That's clever, but a little weird that it changes the behavior of the CATCH BREAKPOINT. I think it would be better to make a new continuation at the THROW and -- I want to say "return it," but of course there's no question of returning something when throwing to a continuation. I guess the CATCH BREAKPOINT would have to have an(other) upvar into which THROW BREAKPOINT could store the new continuation, or something.

Also I think a little weird that you get to return to the breakpoint exactly once. Sounds like you have a very specific application in mind. Yes?

I don't have a specific application; I just decided to give myself the challenge of figuring out how to return to the throw block. You can put multiple throw breakpoint blocks in the catch breakpoint block.

I created some of blocks with help of scratch wiki. But I don't know if it works or not.

May I see the blocks?

But I forgot to save.

oh well

Called it. That's much easier to use. Thanks!

if the item # of the input in list = 1, than it reports 0.