In my server app I want to return a "forbidden" value when the user has no permissions for the endpoint.
To this end I create a rejected promise for reuse:
export const forbidden = Promise.reject(new Error('FORBIDDEN'))
and then elsewhere in the app:
import {forbidden} from './utils'
...
resolve: (root, {post}, {db, isCollab}) => {
if (!isCollab) return forbidden
return db.posts.set(post)
},
However, when I start my app I get the warning
(node:71620) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: FORBIDDEN
(node:71620) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
How can I tell Node that this Promise is fine to be unhandled?
I create a rejected promise for reuse
Well don't, it might be a lot easier to just create a function for reuse:
export function forbidden() { return Promise.reject(new Error('FORBIDDEN')); }
That will also get you an appropriate stack trace for the error every time you call it.
How can I tell Node that this Promise is fine to be unhandled?
Just handle it by doing nothing:
export const forbidden = Promise.reject(new Error('FORBIDDEN'));
forbidden.catch(err => { /* ignore */ }); // mark error as handled
(and don't forget to include the comment about the purpose of this seemingly no-op statement).
I wouldn't recommend using the return statement to provide an Error - this is ignoring the exact intention of throw!
Simply use:
if (!isCollab) throw new Error('FORBIDDEN');
If you don't want a stack trace there's no need to over-engineer - simply do:
if (!isCollab) throw 'FORBIDDEN';
If you need a message property to exist you can simply use:
if (!isCollab) throw { message: 'FORBIDDEN' };
(Note: I recommend against throwing anything other than an instance of Error! You'll regret it later when things break and you need to debug)
OP's usage is not completely described, but the OP's comment "BTW I didn't want to create a stack trace for every forbidden error because I don't want to leak details about my app. So I prefer to create the rejection only once." leads me to believe that at least part of the OP's motivation is to prevent info leakage from unhandled rejections of forbidden.
Returning a rejected (but defused) promise behaves differently in a sync vs. an async function. In the former the promise is returned verbatim. In the latter it is rewrapped in a promised and automatically rethrown (equivalent to throwing from inside the function). Whichever use was intended, it makes the program harder to understand.(Wrapping the Promise to be returned in an object or array would solve that problem).
Difference in behavior between sync and async funcs when returning forbidden :
async function test(){
try {
let a = await (async()=>{return forbidden;})();
} catch(e){console.log(e.message);} // outputs: 'FORBIDDEN'
try {
let a = (()=>{return forbidden;})();
// error undetected
} catch(e){console.log(e.message);} // never reaches here !!!
console.log("something else"); // outputs: something else
let a=(()=>{return forbidden;})(); // UHR + '#<Promise>' + no addr
console.log("something else"); // outputs: something else
await (async()=>{return forbidden;})(); // UHR + '#<Promise>' + no addr leak}
}
test();
Regardless of the the OP's usuage, leakage of program info from unhandled-rejections is a valid concern.
The below factory function makeError would provide a general solution, and it builds on the OP's original inspiration:
const verboten=new Error('verbotten');
const makeError = () => verboten;
async function test2(){
try {
await (async()=>{throw makeError();})();
} catch(e){console.log(e.message);} // outputs: 'verboten'
// uncomment the following to trigger UHR (unhandled rejection)
//await (async()=>{throw makeError();})(); // UHR + 'verboten' + no addr leak
}
Note that makeError returns the constant object verboten, rather than itself. (Yes, that is allowed, although it is rarely used.) So the stack trace is a fixed value, unrelated to the error location in the program, just like the original OP's forbidden.
That's fine for the release version, but a minor change to makeError could be made for a development version, where seeing the stack is useful:
const makeError = Error;
Related
Working on a MERN stack project. When trying to access the site on localhost on iPhone Posts are posts are not loading. Working fine on adnroid devices.
Screenshot of error
const fetchFeedPosts = async () => {
const URL = `${BASE__URL}api/posts/feed/${LOGGED__IN__USER}`;
await axios.get(URL)
.then((response) => setFeedPosts([...response.data].reverse()))
.catch((e) => console.log(e.response));
}
fetchFeedPosts()
What the error means
When an Error is thrown (e.g. throw new Error()) it can
be catched locally (e.g. try{...} catch(err) { /** here */ })
or be passed on to the calling function. And in that fashion it bubbles up from caller to caller until it reaches a catch somewhere.
However, if it continues to bubble up, and there's nothing that captures it by the time it reaches the root of your application or code, then that will result in a so-called "Unhandled" error.
Now, as you may know, promises are more like jobs that drift around. They aren't called from the root of your application. But as they bubble up they can also reach a similar root-point, in which case they become "Unhandled Promise rejections".
What to do about it
Unhandled errors or rejections are bad practice though. Errors should be caught somewhere. And without catching them, you can't really know what has caused the error to happen in the first place.
In most cases, you can catch them with a .catch() function, (e.g. yourPromise.catch((err) => {console.err(err)}))
In case your promise is handled in an async function and waited for with an await keyword, then it's slightly different. In that case it makes more sense to use a try-catch block to capture your error.
How to apply it to your code
So, the first way of doing it would be to use the .catch() function
axios.get(URL)
.then((response) => setFeedPosts([...response.data].reverse()))
.catch((err) => console.error(err));
The alternative is to use the await syntax with a try-catch. If you want to use this syntax, you have to put the async keyword before your function.
try {
const response = await axios.get(URL)
setFeedPosts([...response.data].reverse()))
} catch (err) {
console.log(err);
}
Sure, you could mix the 2, but in most cases that would be rather strange.
My system consists of an Angular UI and a Node API. The UI submits a file to the API for processing, then gets the result back. This all works - however - the API sometimes fails at processing unexpected data.
I want to be able to catch the error(s) when they arise, stop execution so they won't screw up the UI, then send a message back to UI.
Here is my code so far:
const IncomingForm = require('formidable').IncomingForm;
asynch function myApi(req, res)
{
try // (1)
{
var form = new IncomingForm(...);
form.on('file', async(field, file) =>
{
const [result] = await sometimesBad(inParam); // (2) attach .catch(...);
...
res.send({goodFinal}); // execution should not reach here if error occurs before
});
form.on('end', ()=> {})
form.parse(req)
}
catch (erApi) // (3)
{
... // (4)
}
}
async function sometimesBad(x)
{
try // (5)
{
... lines of code could have run-time error depends on x ...
return goodResult;
}
catch(err2) // (6)
{
... // (7)
}
}
Currently, after hours of searching and trial and error, I:
am able to send a message back by chaining a .catch() at (2)
am unable to stop the execution via any combination of (1), (3), (4), (5), (6), (7), including the use of next(), throw new Error(), await Promise.reject(), return Promise.reject().
am always getting UnhandledPromiseRejectionWarning: Unhandled promise rejection.
Node version: 14.9
Update: In addition to accepted answer, there is no need to have (5), (6), (7).
In your code if (2) throws the error indeed is not handled. To handle it, you need to wrap the code inside async (field, file) => ... into try / catch, similar to how you did on the top level of middleware, and inside the catch you do next(error). Also add default error handler after all routes in your app. See How to return error to the client client without making node server crash? regarding that.
You can stop unhandledRejection(s) from crashing your app by handling them. However, if you fail to handle them using catch blocks, you can also watch for events on the process.
Code Example from the Docs:
process.on('unhandledRejection', (reason, promise) => {
console.log('Unhandled Rejection at:', promise, 'reason:', reason);
// Application specific logging, throwing an error, or other logic here
});
somePromise.then((res) => {
return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)
}); // No `.catch()` or `.then()`
Alternatively, you can make your sometimesBad function return a Promise, which would cause all errors happening inside the Promise body to be thrown, which can then be handled in the catch block of the caller.
My question: Is it safe to detach the handling from its Promise object?
If I do this ...
var promise1 = new Promise(function(resolve, reject) {
var json = { "counter":0 }
console.log('execute now, worry later ...')
json.counter++;
console.log(json.counter)
resolve(json);
});
var then = function() {
promise1.then(function(value) { console.log('value: '+value.counter) });
}
setTimeout(then, 3000);
var promise2 = new Promise(function(resolve, reject) {
console.log('error thrown here ...')
throw new Error('will it behave the same as with then?');
});
var catchFunc = function() {
promise2.then().catch(function(error) { console.log('error: '+error.message) });
}
setTimeout(catchFunc, 3000);
Then I get warnings that make sense ...
execute now, worry later ...
1
error thrown here ...
(node:9748) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: will it behave the same as with then?
(node:9748) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
value: 1
error: will it behave the same as with then?
Background: In some cases, I want my promises to run concurrently. In some cases, I would like them to be run sequentially. The simplest implementation I've found is to wrap both variants into a function, push it in a map, and treat the "then / catch" in a reduce. The result is that my handling in the first variant (concurrently) is at the time of the wrapping and detached as in my sample above.
If it is safe, how can I remove the warnings from my log?
Rejected promise should be chained with catch on same tick. If this doesn't happen, UnhandledPromiseRejectionWarning appears. It's expected to become an exception in next Node versions, so it's should be avoided.
Once promise control flow was introduced, it's beneficial to use promises. setTimeout stands out and doesn't provide error handling for promises.
If promises are processed concurrently, they are usually handled with Promise.all(...).catch(...). In this case resulting promise is chained with catch on same tick (a similar problem is addressed in this answer).
So I have been working on a react native application just like the meetups app.
It has its own node.js backend which can be viewed here
https://github.com/rahullakhaney/meetup/tree/master/meetup-backend
While in my application, I am trying to populate the groups from my database, I get this error "Possible unhandled promise rejection (id:0) null is not an object"
Here is my api.js file
import axios from 'axios';
axios.defaults.baseURL = 'http://localhost:3000/api';
const fakeGroupId = '58d64e3a122149dd3cdba5d8';
class MeetupApi {
constructor() {
this.groupId = fakeGroupId;
this.path = `/groups/${this.groupId}/meetups`;
}
async fetchGroupMeetups() {
const { data } = await axios.get(this.path);
return data.meetups;
}
}
export {
MeetupApi
};
You can also view the complete code at https://github.com/rahullakhaney/meetup/tree/master/meetup-mobile
Can anyone please explain why am I getting this error, sorry but I am new to react native.
Every function or method declared with the async keyword returns a promise. That promise is resolved when you return something from that function and it is rejected when you throw an exception in that function.
When you write this:
const { data } = await axios.get(this.path);
then what really happens is that you add a resolve callback to the promise returned by axios.get() but every rejection of that promise returned by axios.get() is raised as an exception inside of the fetchGroupMeetups() method. You don't use try/catch so that exception propagates and is in turn converted into a rejection of the promise that is returned by fetchGroupMeetups() - which you probably don't handle.
To handle that rejection you either need to use it as something like:
x.fetchGroupMeetups(...).catch(err => console.log('Error:', err));
or, inside of other async function:
try {
x.fetchGroupMeetups(...);
} catch (err) {
console.log('Error:', err);
}
but of course doing something more than just printing the error.
To know more details on what are those unhandled rejections and why you should always handle them, see this answer:
Should I refrain from handling Promise rejection asynchronously?
TL;DR: The unhandled rejections used to be warnings but will now crash your app. Here is why.
When the Bluebird module detects a non-Error reject, it reports Warning: a promise was rejected with a non-error.
So when we are writing a reusable promise library, how should we handle the situation when it is the client's code that throws simple values?
Simple my-library example:
var Promise = require('bluebird');
module.exports = function (cb) {
return new Promise(function (resolve, reject) {
try {
cb();
resolve('some data');
} catch (e) {
// should we do this?
reject(e);
// or should we do this?
// reject(e instanceof Error ? e : new Error(e));
}
});
};
A client that consumes it:
var lib = require('my-library');
lib(function () {
throw 'Regular text';
})
.catch(function (error) {
// - should we expect exactly 'Regular text' here?
// - or should it be wrapped into Error by the promise library?
});
In the example above we are going to see the same Warning: a promise was rejected with a non-error again, which in this case is obviously the client's fault, but the problem is - it will be reported against the promise library that did the reject.
This brings a question of how a reusable library should handle such cases.
Option 1: do nothing (just use reject(e)), let the client see the warning message Warning: a promise was rejected with a non-error.
Option 2: verify if the error thrown is an instance of Error and if not - do reject(new Error(e)). This enables the client to throw and reject with simple values, which is probably bad.
I am looking for a general recommendation here.
Also consider that sometimes the client can be an old library that you are trying to wrap into promises.
You should definitely and objectively wrap non-errors with errors.
Non errors are terrible for debugging, the bluebird warning is there because it is very hard to figure out where an error came from if it's a primitive. You can't attach properties to primitives and they have no stack traces.
Stack traces mean you don't have to guess where the errors come from - you know.
That said, bluebird already does this automatically with promisify and promisifyAll and consider using them. If you're doing this manually - just make sure you throw or reject things with stacks too.
Node in addition looks for the stack traces of your unhandled rejections - so rejecting with junk will not only give you useless information in Node but it might actually crash your program.
Error messages should be wrapped in error objects, but not automatically.
Automatic wrapping reduces the usefulness of stack traces. For example, lets say the client function is f and your library function is g:
function f(x) { throw 'Hello world' }
function g(f, x) { try { f(x); } catch (e) { throw new Error(e); } }
g(f, 1)
The client function and line numbers where the error originated will be completely missing from the stack:
Error: Hello world
at g (repl:1:52)
at repl:1:1
While if the client function creates the error object:
function f(x) { throw new Error('Hello world'); }
function g(f, x) { try{ f(x); } catch (e) { throw e; } }
g(f, 1)
we get a full stack trace:
Error: Hello world
at f (repl:1:23)
at g (repl:1:25)
at repl:1:1
There is no way to recover the stack up to the point in your library, making it useless for users (they wont be able to debug their own code).
That said, this largely depends on what sort of library you're making and what sort of contract you would like it to present to the users. You should think very carefully before using user-passed callbacks, as they invert the normal chain of responsibility in the stack.
Promises make this easier because they un-invert the inversion: the library is called first to generate a promise, then that promise is passed a callback. As such, creating a new error together with the creation of the promise allows Bluebird to at least partially look into / augment the stack of the client code (the line that created the promise will be present in the stack). The warning is still there because its impossible to provide a complete stack.
No, they simply want you to wrap your JSON error objects into something.
This is not freedom, it's dictature.
There's no point in wrapping simple JSON objects in bulky Error wrappers.
Don't listen to them.