component / model

Minimalistic extensible data models
122 stars 40 forks source link

Implementation opt-in error handling #8? #65

Open fschoenfelder opened 10 years ago

fschoenfelder commented 10 years ago

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 (https://github.com/component/model/issues/8) also? I'm excited about your feedback!

Frank.

timaschew commented 10 years ago

please give some feedback, btw who is the maintainer?

vendethiel commented 10 years ago

It seems @juliangruber is :)

juliangruber commented 10 years ago

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

timaschew commented 10 years ago

so @ianstormtaylor what you think ;)

ianstormtaylor commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

+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...