Gil Pedersen

`Error` is still the correct type for the argument. If a non-Error is passed, another non-Boom `Error` will be thrown, which means that you did something wrong when calling the...

Actually, a breaking change that always returns a `Boom` object is probably the best way forward. It is unfortunate that `throw boomify(err)` risks throwing a non-Boom error.

Hapi already takes measures to [ensure it doesn't pass non-Errors](https://github.com/hapijs/hapi/blob/74d6b52bac3f8d159b12ba7eb6d4d4d1bd8e361e/lib/toolkit.js#L66-L71), which could be avoided. It would also fix [this url parsing logic](https://github.com/hapijs/hapi/blob/5999a6027fdedfa28c2317921e2fae56f4f55bcd/lib/request.js#L127-L135), where a custom query `parser` can throw non-Errors,...

As I see it, the current implementation and type signature would also be valid for TS, except the check would be done using an assertion. It is not unheard of...

Thanks for the overview. As you probably guess I favour option 2. Option 4 seems intriguing, but I would prefer not to go that route, unless someone can demonstrate a...

I would probably do it like `new Boom.Boom()`. Having another look at it, I'm conflicted about going for 2, since `boomify` is clearly documented to only work on errors and...

The weird error comes when one of the test lines throw an error.

When dealing with typescript, another helper method might be handy. Something like `Bounce.assert(err)`, which will throw a system error if `err` is not `instanceof Error`. It would have a signature...

@hueniverse Yeah, I see that you have converted some of your modules. I guess you have changed your stance on authoring modules in Typescript? While the TS code conversion is...

Personally, I would much prefer to do a breaking change to `boomify`, as suggested in https://github.com/hapijs/boom/issues/291#issuecomment-997863811, which would also update the argument type to `any`.