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

next() function needs an argument for indicating an error #1

Open
lukehesluke opened this issue Jun 16, 2017 · 2 comments
Open

next() function needs an argument for indicating an error #1

lukehesluke opened this issue Jun 16, 2017 · 2 comments

Comments

@lukehesluke
Copy link

The next() function handed to calls to init(), start() and stop() should have an argument for indicating an error. So you can do something like:

start: function(next) {
  someFunctionReturningAPromise().then(function() {
    throw new Error('something bad! D: D:');
    next();
  }).catch(function(err) {
    next(err);
  });
}

This above should then attempt to shut down all previously started dependencies. If there's an error in a service's stop(), it will just have to be aborted and continue stopping other dependencies. After the full shutdown, either all errors or the first should be thrown, so as to notify the user what's happened

As far as I can tell there's no process for handling errors (especially asynchronous ones) at the moment

I can happily work on this myself or help out. Lemme know your thoughts

@quile
Copy link
Owner

quile commented Jun 19, 2017

Hey thanks for this - much appreciated. I'm going to give it some thought; I don't want to rush into anything just yet. I'm not sure I want to proscribe a particular way of handling errors, although you may be right and it may be as simple as propagating errors to the next() function.

Off the top of my head, my general thinking is that components are responsible for their own error handling; passing errors down the chain doesn't actually mean anything because you have no guarantee which component will be called next (and it's not ever something you can rely on; only that your dependencies will be started first). Instead it might be better to have the Lifecycle methods catch any exception and shut down any started components (or bail with prejudice if shutting them down is not an option), which I think is similar to what you're suggesting.

@lukehesluke
Copy link
Author

lukehesluke commented Jul 3, 2017

Sounds like we're agreed, @quile :)

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

2 participants