error handling with seneca-web 1.0.0

[allinwind3344]

when seneca action encounter fatal error, it may terminate seneca-web.
check the issue #56, can handle error as below:

seneca.act('role: web', {use: {
  prefix: '/',
  pin: 'role: user, cmd: *',
  map: {
    read: {GET: { responder : handle_response}, alias: '/user/:userId'},
    create: {POST: { responder : handle_response}, alias: '/user'}
  }
}})

whether "responder" still exist in seneca-web 1.0.0? if not, how to customize error handling?

[mcdonnelldean]

@allinwind3344 All action handlers have access to the request and response objects. So to do the above you can do.

seneca.act('role:web', {routes: {
  prefix: '/',
  pin: 'role: user, cmd: *',
  map: {
    read: {GET: true, alias: '/user/:userId', autoreply:false},
    create: {POST: true, alias: '/user', autoreply:false}
  }
}})

Then in your handler,

seneca.add('role:user,cmd:read', (msg, done) => {
  // The req, res provided by the adapter.
  var requestObj = msg.request$
  var replyObj = msg.response$

  // Tell seneca you are done
  done()

  // It is now up to you to reply
 replyObj.xyz // Differs depending on adapter used
})

Do not auto handlers are the only type of web route that can participate in transport. To put it another way request$ and response$ are not transported over the network so cannot be handled in another microservice.

[tswaters]

Maybe it would be good to provide a next function to routes and if an error occurs route it through there. Not having custom error handling over transport is a pretty substantive limitation

I'm not sure how this could work in HAPI but with express/connect it would allow the host application to handle errors in a custom error handler. Currently errors are always returned as 500, sending the entire error.

[mcdonnelldean]

If it can be made to work generally with all adapters I'm all for it. I want to avoid specific functionality differences where possible.

[tswaters]

Fair enough.... I'll look into this later today. Heading into work now but in ~8-9 hours I'll look into how this can be done in hapi/koa

[tswaters]

After playing with this a bit, it seems that each of the adapters has a method for the host application to handle errors except for connect/express... I've opened tickets on each of the adapters for this and have attached PRs to fix each (see above for tickets)

For prosperity, here's how to handle errors in each of the adapters

• hapi - attaching onPreResponse extension and checking for isBoom and replying with something custom
• koa1/2 - attaching middleware at the top that awaits/yields next; one can catch the error and reply
• connect/express adding a error handler via app.use((err, req, res, next) => {}) (todo - see above tickets)

I've added/updated the test cases in each of the adapters to show some usage of this. (also, @mcdonnelldean, this test case brings HAPI is back up to >80% coverage, so I've bumped it up again)

[mcdonnelldean]

@tswaters epic stuff. We'll probably need a doc on this.

[allinwind3344]

@mcdonnelldean thanks for your explanation!
@tswaters thanks for your great work!

[sandeepmalviya581]

how to use boom for exception handling in seneca js ?