To develop a library, should we throw errors / exceptions?
I am developing a pub / sub Mediator library that will be used by others and I have no idea how to handle errors.
Here's a sample snippet of code:
/**
*
* @param String channel Channel to subscribe
* @param String|function callback Function name or callback
* @param String context Context to bind function to
* @param Boolean once True to subscribe once
**/
this.subscribe = function (channel, callback, context, once) {
if (!_.isObject(context)) {
context = window;
}
if (!_.isFunction(subscription) && !_.isFunction(context[subscription])) {
throw new Error('Function passed as callback to channel subscription named ' + channel + ' seems invalid!');
}
// Everything ok, add to channels object
channels[channel].push({fn: subscription, context: context || this, once: once});
}
This method is part of the library. It API expects a channel name and a valid callback (either a function name, or a lambda, or a callback).
If the pipe argument is not a string, the library stops easily. If an invalid context is passed, a window is assumed. Errors in both of these parameters are easily absorbed.
However, if an invalid callback is passed, it propagates the error until the event is fired (a channel post is created). In a pub / subsystem, this can become a debugging nightmare if, for example, an event rarely fires.
So my question is ...
In this particular scenario, taking into account that I am developing a javascript library for others, should I:
- throw Errors to prevent further propagation of errors?
- return false / undefined / - 1 and not register a subscription?
- act as usual to let it die somewhere, leaving debugging to a third party developer
Note: There's a similar question , but my situation is slightly different and the answers provided did not calm my spirit.
source to share
Option # 3 should be avoided. At least return false;
. You can even register the wrong callback, expecting no events to be posted (since something went wrong). This "silent failure if not everything went wrong" may not apply to your pub / sub example, but there may be use cases for it.
Option # 2 sounds pretty good. This somehow makes the parameter callback
explicitly optional, which might be a feature of your library - if the user isn't sure if they have a reason to subscribe, they can omit this test if you do it anyway. You can combine this with the post console.warn()
in the debug versions.
Option # 1 should be chosen if something really unexpected happened. This allows you to crash with a very descriptive custom error message. This could be the case if the callback is a truthful object but not callable, or the channel argument is boolean or something - depending on how closed your interface design is / how much you overload (in your case, you can accept strings for be evaluated as callbacks or channel string arrays, for example).
source to share
I think this answer is bigger than my opinion and what I am following. You should ask yourself if you should return an error and let the consumer of your library handle that error. If the error is something that cannot be recovered from, you don't need to throw the error (in JS). Your library should be able to fallback to alternatives with ease, but if it can't do that for a particular function, it should return undefined. Most JS developers check for undefined, which is a fairly common practice when using library functions. Returning false is usually done by event handlers if the event cannot be handled.
source to share