Fix errors

[flintinatux]

In the past, sox has been less than helpful auto-wrapping vanilla errors with Boom representations. They all just ended up as 500's, and the original message was lost in time and space.

Now we can surface those custom error messages. You'll still get a 500, but the message property should be helpful.

to test:

• Read the code.
• Wait for the green.
• Find a squirrel in sox.

[mgreystone]

Code looks good, but i'm confused. I assumed we purposefully swallowed error details just like hapi & paperplane?

[mgreystone]

Are we locking sox to node 8 just for boom?

[flintinatux]

I double-checked our repos, and we don't use sox in anything less than node 8, so I figured it was safe.

[spencerfdavis]

💯

[flintinatux]

@mgreystone, looking back at the client-side portion of sox after our talk earlier, I'm seeing this in client/toError.js:

const toError = ({ data, message, name, status }) => {
  const err = new Error(message)
  err.data = data
  err.name = name
  err.status = status
  return err
}

We already treat message and name coming in from the server as though they are different values. In Boom they are always the same, but that's irrelevant. I'm thinking that having a message string that's helpful isn't a serious bleed of information, and that passing structured data along with it the way you did in the past is also good. And if it's something we want to backport to paperplane so we're consistent, then that's good too.

[spencerfdavis]