-
Notifications
You must be signed in to change notification settings - Fork 65
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
fixes #35
fixes #35
Conversation
Also, I'm curious what influenced the decision to remove |
Thanks @throwarray, I will review this PR soon. About the removal of
Previous app.use(thisWork)
app.use(thisThrow) // throw here
app.use(thisWork1) // always skip
app.use(thisWork2) // always skip
app.use(anerrormiddleware) // handle error
// it's over, no way back Now app.use(thisWork)
app.use(thisThrow) // throw here
// simply calling .onError here and if next is called...
app.use(thisWork1) // may continue
app.use(thisWork2) // may continue
app.use(thisWork)
app.use(anerrormiddleware) // skip because there is no error
app.use(thisThrow) // throw here
app.use(thisWork1) // skip. uh oh where is the error middleware
app.use(thisWork2) // skip. oh no
|
I think one thing I miss is the convenience of using multiple error middleware.
Perhaps a future version will accept an array of middleware for |
Thanks @throwarray, close in favor of #38 |
@hoangvvo it does seem better to have it just be the apply method. |
handler.get(async function () {
await new Promise(function (resolve, reject) {
setTimeout(function () { reject(new Error('error')) }, 100)
})
}) |
@throwarray This is definitely a bug. I just reproduce it locally. I will try to get a fix in |
fixes #30