Why does seneca override eraro ? / Error management proposal

[jeromevalentin]

In seneca 3.2.1, when an error is thrown during an act call, it is correctly handled and forwarded to caller.
But the exception is being wrapped in a seneca eraro 'act_execute' error which is not useful for the caller!

I tried to use eraro directly (as it match my need to send internationalizable error code (plus details) to remote caller).

Unfortunately, seneca is also overriding eraro errors!! see: seneca.js line:43
So as a first quick step, would it be possible to change the override: true to false? or make it customizable?

Concerning error management, the version 3 helps a lot by catching thrown error in act automatically.

But from my point of view, seneca should not log, not wrapping such business error it as it is part of the service signature. Globally, there are two kind of errors:

• Unexpected errors: service implementation bugs. The caller must know what happens even if it failed unexpectidely (wrapping such error in an eraro with unexpected_error code may be a solution)
• Business errors: I would suggest to define a property business:true in service business errors to tell seneca to let the exception goes out without log nor wrapping it as it is part of the standard service signature!

Regards and thanks for the job guys, this library rocks ;)
Jérôme

[Tapppi]

I actually do these things as a wrapper for all of our internal seneca usage, but it would be cool to have it in seneca proper. Basically what I do is, I have a businessError property on all of my business errors set to true and false on all of my errors that should be handled as fatal (e.g. fatal responses from third-party libraries, fatal database errors). This property is then used in our wrapped add (addAsync as it also handles async functions) to determine whether the error should be passed to seneca or the caller. It would be cool if seneca did handle this more gracefully, but I remember there being larger discussions around error handling as well (found it: #398).

[StarpTech]

Hi @jeromevalentin error management is a big topic. It's not consistent and need a rewrite.

#574 (comment)
#514

Follow this issue for the best results #398

[rjrodger]

Yes lots of work to do here - and indeed the current system needs to at least be documented.
The returned error does include the original exception in the orig property.

A further complication to note is that messages may be transported over the network to non-JS systems, so simply passing a JS Exception directly is not feasible either.

[rjrodger]

FYI starting some work on this: https://github.com/rjrodger/seneca/blob/master/test/error.test.js#L60

[StarpTech]

Hi @rjrodger if you have time you could check my error handling in hemera. I use https://github.com/busbud/super-error to create custom errors and for preserving the error chain.
To reconstruct the error I use https://github.com/programble/errio. It fits really well.

• You can use instanceOf to check your error even across process boundaries.
• Error details are preserved