Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling #10

Open
vorg opened this issue Feb 9, 2018 · 4 comments
Open

Error handling #10

vorg opened this issue Feb 9, 2018 · 4 comments

Comments

@vorg
Copy link

vorg commented Feb 9, 2018

Currently emitting invalid state transition emits error nanostate.emit: invalid transition ${this.state} -> ${eventName}.

Do you have any ideas on how to handle those errors? E.g.

var machine = nanostate('cash', {
  cash: { check: 'check' },
  check: { cash: 'cash' }
})

machine.onError((e) => {
  console.log(error)
  throw e
})

machine.emit('robbery')
@kareniel
Copy link
Member

kareniel commented Feb 10, 2018

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

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Feb 12, 2018

@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
Copy link

bcomnes commented Feb 12, 2018

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

@vorg
Copy link
Author

vorg commented Feb 12, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants