Implementation opt-in error handling #8?

[fschoenfelder]

Hey,

we have implemented a model plugin to handle errors. It's necessary for this, to get request errors (e.g. timeout/crossdomain) and return them on the "end" of a request.
Furthermore it's possible with this modification to manipulate the error info/data that is passed to the model callbacks (e.g. save( function(err){} )).

Perhaps this was something you meant with this issue (#8) also?
I'm excited about your feedback!

Frank.

[timaschew]

please give some feedback, btw who is the maintainer?

[vendethiel]

It seems @juliangruber is :)

[juliangruber]

i'm not the only one :P see https://github.com/component/model/graphs/contributors

[timaschew]

so @ianstormtaylor what you think ;)

[ianstormtaylor]

sounds interesting, but i dont quite understand the use case. would you really want a single function to handle all types of errors? i havent run into the need for this, but havent been dealing with errors much

[fschoenfelder]

You're right. One option is to handle all errors in the 'toError(fn)' function.
It is also possible to handel errors by case.
For example to convert or 'refine' an error before it is passed/returned to the callback (e.g. Model.get(cb) - static.js:196).
Another option would be to notify about the error in toError(fn), e.g. by emitting the error, and handle it for a model object or static.
In our case, we use an own model plugin to handle errors either by a central error handler or by using the callback 'err' param and wrap some error handling code.
In my opinion there are be several different usages when it's possible to 'inject' some code in the model internal error handling process.

[clintwood]

+1, this is something I use (and one of the reasons for my own Model implementation)...
Essentially what @fschoenfelder is saying, injecting common error/response handling per model type allows pre-conditioning of response data or errors in one place before handing back to the normal local response handling function... @ianstormtaylor, many use cases...