I'm using rxjs in a library to expose an Observable that clients can subscribe to to consume messages. I want to be able to react appropriately if the subscriber's next function throws an error. However, I'm not seeing any obvious way to detect that. For example:
const observable = new Observable<string>((subscriber) => {
subscriber.next('first')
subscriber.next('second')
subscriber.complete()
})
observable.subscribe(() => {
throw new Error('oh no!')
})
I have tried all of the following, but the errors are bubbled all the way up to a global scope that's surfaced either in an onUnhandledError function provided to the global config, or in absence of that, the node process's unhandledException event.
process.on('uncaughtException', (error) => {
console.error('IN UNCAUGHT EXCEPTION HANDLER', error.message)
})
export function main() {
try {
const observable = new Observable<string>((subscriber) => {
try {
subscriber.next('first')
} catch (error) {
console.error('IN OBSERVABLE CATCH', error.message)
}
subscriber.complete()
}).pipe(
catchError((error) => {
console.error('CATCHERROR PIPE', error.message)
return of('there was an error!!!!')
}),
)
observable.subscribe({
next: (_value) => {
throw new Error('oh no!')
},
error: (error) => {
console.error('IN OBSERVER ERROR HANDLER', error.message)
},
complete: () => console.log('complete!'),
})
} catch (error) {
console.error('IN MAIN CATCH', error.message)
}
}
This logs:
complete!
IN UNCAUGHT EXCEPTION HANDLER oh no!
The docs don't make a big fuss about ensuring that subscribers avoid throwing errors at all costs, but I don't see a standard mechanism for handling it short of some sort of "observer wrapper" (that gets a bit ugly with the overloads).
Turns out that there is effectively no way to handle errors from observers.
When using Observable.subscribe, it wraps your observer functions in a "SafeSubscriber". This then wraps the supplied functions with a ConsumerObserver. This wraps each in a try/catch that, upon errors, either:
sends them to an optional onUnhandledError function you can supply to the rxjs config
sends them "into the ether" to be picked up by the node process
There is no context, and no way to hook into it. Effectively, errors from next, error, or complete handlers just silently disappear.
Related
I started working with NodeJS a couple weeks ago. I am wondering what is the best way to handle errors in NodeJS?
Right now, I am doing it in all my controllers methods. For example:
exports.myMethod = async (req, res, next) => {
try {
// My method operations here
} catch(err) {
const email = new Email(); // This is a class that I create to notify me when an error happens. errorEmail(mailBody, mailSubject)
await email.errorEmail(err, "Email Subject - Error");
}
}
Is it a good way? I mean, is there a better/more efficient way to handle errors in NodeJS?
Thanks
Error handling when using Promises (or async/await) is pretty straight forward. You don't want to have lots of duplicates of error handling code and extra try/catch blocks all over the place.
The way I find best is to put the error handling at the highest possible level (not deep in the code). If an exception is thrown, or a Promise rejects, then the failure will percolate up to the point where you catch it and handle it. Everything in between doesn't have to do that if it's handled once at the appropriate place.
So your code can start looking cleaner like this:
// module #1
exports.myMethod = async () => {
// My method operations here
return result;
}
// module #2
exports.anotherMethod = async () => {
const result = await module1.myMethod();
// do more stuff
return anotherResult;
}
// module #3
exports.topMethod = () => {
module2.anotherMethod()
.then((res) => {
console.log("all done", res);
})
.catch((err) => {
const email = new Email(); // This is a class that I create to notify me when an error happens. errorEmail(mailBody, mailSubject)
email.errorEmail(err, "Email Subject - Error")
.then(() => console.log("done, but errors!", err);
});
}
The nice thing here is that the only place I have to add extra error handling is way at the top. If anything deep in the code fails (and it can get much more deep) then it will just return up the chain naturally.
You are free to put .catch statements anywhere in between for doing retries, or to handle expected errors quietly if you want, but I find using .catch is cleaner that wrapping sections of code with try/catch blocks.
I have a code like this (simplified):
getStreamFor(path) {
// both, remote and local, return a Promise
if(...) { return getRemoteFileStream(path); }
else { return getLocalFileStream(path); }
}
getRemoteFileStream(path) {
// should throw in my case (MyError)
const validPath = validatePath(path);
return readStreamIfValid(validPath);
}
and in the test case:
it('should throw MyError', () => {
return getStreamFor(path)
.then(() => {})
.catch(error => expect(error).to.be.instanceOf(MyError));
});
The problem is, that when the validatePath(path) Method throws (due to invalid path), nothing get caught in the test case promise. The output in my terminal / console is a regular exception as if it was uncaught.
Does anybody have an idea, why the the Promise wouldn't recognize the throw? How can I fix it without probably surrounding the call in the test case with another "try catch" (since the promise should do that for me)?
Maybe there is a general best practise how to structure Promises in order to avoid error swallowings like these?
Thanks for your help!
The problem here is that validatePath() is not part of the promise chain returned by getRemoteFileStream()
One possible solution is the following:
getRemoteFileStream(path) {
return Promise.resolve()
.then(() => validatePath(path))
.then(validPath => readStreamIfValid(validPath));
}
An exception thrown by validatePath() would now be handled in the Promise's catch handler.
I have a Express router with specific request handler:
router.post(def.doc_create, handle);
async function docCreate(req, res) {
let metadata = mapper.mapObject(req.body, templates.document_create_rq);
let relatedVers = mapper.mapArray('dms$relatedDocuments', templates.related_doc_vers, req.body).items;
// if (req.body['dms$mchMetadata']) {
try {
let productInstanceIds = req.body['dms$mchMetadata']["pro$productInstanceIds"] || [];
} catch (err) {
throw new Error(err.message);
}
....
}
'safeHandleReq' method will pick up the right handler for given route from the pre-initialised map and will call it:
class SafeRequestHandler {
constructor(reqMappings) {
this.mappings = reqMappings;
}
safeHandleReq(req, res) {
try {
let pair = _.find(this.mappings, {'url': req.url});
return pair.handler(req, res);
} catch (err) {
return sendEnhaced(err, res);
}
}
}
with this handler being executed in try-catch I wanted to avoid UnhandledPromiseRejectionWarning: Unhandled promise rejection errors. This happens for example, where there is no such property in req.body that I'm asking for. Now exactly this happens in try-catch block I have shown here. The request's body does not contain dms$mchMetadata property at all. Now I have expected the catch block of the handler to be hit. But it's not. Even when I re-throw caught error in the 'docCreate' handler itself, safeHandleReq's handler catch block won't catch the error, but forementioned error is being written on the console instead.
I need to be able to catch all sorts of this errors in handler's catch block because there is many places where anticipations can go wrong and I need to return (somethong). When the error is not caught execution hangs and Express won't respond.
So why and what I need to do in order to be able to catch all errors from handler implementation in the safeHandleReq try-catch block? I need a systematic solution.
Thanks for recommendations!
I'm using nock.back to mock out some API calls. When unexpected calls are made, UnhandledPromiseRejectionWarning gets printed to the console, but my tests pass, and those warnings are easily missed in the rest of the console output. I want an exception thrown instead of a silent error. How do I do this?
The way I use promises is:
function myFunction(){
return new Promise((resolve, reject) -> {
try {
// Logic
resolve(logic)
} catch(e) {
reject('Provide your error message here -> ' + e)
}
})
}
Or !
function myFunction().then( // Calls the function defined previously
logic => { // Instead of logic you can write any other suitable variable name for success
console.log('Success case')
},
error => {
console.log('myFunction() returned an error: ' + error)
}
)
UPD
Have you had a look here? https://nodejs.org/api/process.html#process_event_unhandledrejection
It describes an unhandledRejection event being emitted when you have no catch for a rejection from a Promise and provides the code to catch the WARNING and output it nicely to console.
(copy paste)
process.on('unhandledRejection', (reason, p) => {
console.log('Unhandled Rejection at:', p, 'reason:', reason);
// application specific logging, throwing an error, or other logic here
});
Node.js runs on a single process.
I'm writing a JavaScript function that makes an HTTP request and returns a promise for the result (but this question applies equally for a callback-based implementation).
If I know immediately that the arguments supplied for the function are invalid, should the function throw synchronously, or should it return a rejected promise (or, if you prefer, invoke callback with an Error instance)?
How important is it that an async function should always behave in an async manner, particularly for error conditions? Is it OK to throw if you know that the program is not in a suitable state for the async operation to proceed?
e.g:
function getUserById(userId, cb) {
if (userId !== parseInt(userId)) {
throw new Error('userId is not valid')
}
// make async call
}
// OR...
function getUserById(userId, cb) {
if (userId !== parseInt(userId)) {
return cb(new Error('userId is not valid'))
}
// make async call
}
Ultimately the decision to synchronously throw or not is up to you, and you will likely find people who argue either side. The important thing is to document the behavior and maintain consistency in the behavior.
My opinion on the matter is that your second option - passing the error into the callback - seems more elegant. Otherwise you end up with code that looks like this:
try {
getUserById(7, function (response) {
if (response.isSuccess) {
//Success case
} else {
//Failure case
}
});
} catch (error) {
//Other failure case
}
The control flow here is slightly confusing.
It seems like it would be better to have a single if / else if / else structure in the callback and forgo the surrounding try / catch.
This is largely a matter of opinion. Whatever you do, do it consistently, and document it clearly.
One objective piece of information I can give you is that this was the subject of much discussion in the design of JavaScript's async functions, which as you may know implicitly return promises for their work. You may also know that the part of an async function prior to the first await or return is synchronous; it only becomes asynchronous at the point it awaits or returns.
TC39 decided in the end that even errors thrown in the synchronous part of an async function should reject its promise rather than raising a synchronous error. For example:
async function someAsyncStuff() {
return 21;
}
async function example() {
console.log("synchronous part of function");
throw new Error("failed");
const x = await someAsyncStuff();
return x * 2;
}
try {
console.log("before call");
example().catch(e => { console.log("asynchronous:", e.message); });
console.log("after call");
} catch (e) {
console.log("synchronous:", e.message);
}
There you can see that even though throw new Error("failed") is in the synchronous part of the function, it rejects the promise rather than raising a synchronous error.
That's true even for things that happen before the first statement in the function body, such as determining the default value for a missing function parameter:
async function someAsyncStuff() {
return 21;
}
async function example(p = blah()) {
console.log("synchronous part of function");
throw new Error("failed");
const x = await Promise.resolve(42);
return x;
}
try {
console.log("before call");
example().catch(e => { console.log("asynchronous:", e.message); });
console.log("after call");
} catch (e) {
console.log("synchronous:", e.message);
}
That fails because it tries to call blah, which doesn't exist, when it runs the code to get the default value for the p parameter I didn't supply in the call. As you can see, even that rejects the promise rather than throwing a synchronous error.
TC39 could have gone the other way, and had the synchronous part raise a synchronous error, like this non-async function does:
async function someAsyncStuff() {
return 21;
}
function example() {
console.log("synchronous part of function");
throw new Error("failed");
return someAsyncStuff().then(x => x * 2);
}
try {
console.log("before call");
example().catch(e => { console.log("asynchronous:", e.message); });
console.log("after call");
} catch (e) {
console.log("synchronous:", e.message);
}
But they decided, after discussion, on consistent promise rejection instead.
So that's one concrete piece of information to consider in your decision about how you should handle this in your own non-async functions that do asynchronous work.
How important is it that an async function should always behave in an async manner, particularly for error conditions?
Very important.
Is it OK to throw if you know that the program is not in a suitable state for the async operation to proceed?
Yes, I personally think it is OK when that is a very different error from any asynchronously produced ones, and needs to be handled separately anyway.
If some userids are known to be invalid because they're not numeric, and some are will be rejected on the server (eg because they're already taken) you should consistently make an (async!) callback for both cases. If the async errors would only arise from network problems etc, you might signal them differently.
You always may throw when an "unexpected" error arises. If you demand valid userids, you might throw on invalid ones. If you want to anticipate invalid ones and expect the caller to handle them, you should use a "unified" error route which would be the callback/rejected promise for an async function.
And to repeat #Timothy: You should always document the behavior and maintain consistency in the behavior.
Callback APIs ideally shouldn't throw but they do throw because it's very hard to avoid since you have to have try catch literally everywhere. Remember that throwing error explicitly by throw is not required for a function to throw. Another thing that adds to this is that the user callback can easily throw too, for example calling JSON.parse without try catch.
So this is what the code would look like that behaves according to these ideals:
readFile("file.json", function(err, val) {
if (err) {
console.error("unable to read file");
}
else {
try {
val = JSON.parse(val);
console.log(val.success);
}
catch(e) {
console.error("invalid json in file");
}
}
});
Having to use 2 different error handling mechanisms is really inconvenient, so if you don't want your program to be a fragile house of cards (by not writing any try catch ever) you should use promises which unify all exception handling under a single mechanism:
readFile("file.json").then(JSON.parse).then(function(val) {
console.log(val.success);
})
.catch(SyntaxError, function(e) {
console.error("invalid json in file");
})
.catch(function(e){
console.error("unable to read file")
})
Ideally you would have a multi-layer architecture like controllers, services, etc. If you do validations in services, throw immediately and have a catch block in your controller to catch the error format it and send an appropriate http error code. This way you can centralize all bad request handling logic. If you handle each case youll end up writing more code. But thats just how I would do it. Depends on your use case