Error handling

[choojs]

Error handling

[kareniel]

I wouldn't.

Better make sure the string passed to machine.emit() is a registered event in the first place.

Here's a line from the choo readme that summarizes why:

We use the require('assert') module from Node core to provide helpful error messages in development. In production you probably want to strip this using unassertify.

Do you feel like there would be a good case for managing invalid transitions internally?

I could imagine two ways this could work. Maybe:

1. we could emit an event. a nanostate instance is already an event emitter which means .on is already exposed; the pattern should probably be: machine.on('error', ...)
2. we could return a list of all possible states so that consumer can run the check in the application code. this comes at the cost of being tiny. maybe it's worth it? i don't know ¯\(ツ)/¯

For now I try to make sure I emit only registered event names.

I hope this helps :)

---

edit:
found these thoughts on the subject:

1. /javascript-state-machine/docs/error-handling.md

[vorg]

Hi, Yes it makes sense. For now i can also validate potential changes by accessing machine.transitions which is enough for me.

On Mon, 12 Feb 2018 at 16:44, Bret Comnes ***@***.***> wrote: I'm going to prioritize that next, should be a fairly easy addition. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKb-Q7oRFQD-jbM4-sWDr71Exnh6lywks5tUGqJgaJpZM4SASW8> .

-- Marcin Ignac

[yoshuawuyts]

@vorg hey, yeah - so the idea behind throwing an error here is that you've made a mistake in the logic. In any given scenario, if you hit an invalid transition, there's no good way to recover from that. Which state did you intend to go? Which state should we be in to recover? There's no good answer.

So we throw, and hope a developer spots the mistake and fixes the source.

As per choojs/nanocomponent#43 for use within nanocomponent, we'll have error boundaries in the (near) future. These are basically try..catch blocks around all internal methods, calling an optional error handler if something goes wrong.

Does this make sense?

[bcomnes]

I'm going to prioritize that next, should be a fairly easy addition.