We Keep Coding

Static/dynamic way to detect dangling promises

I know this problem has been dealt with so many times, but none of them seem to solve the issue of reliably detecting dangling promises (even those that resolve properly).
So I want to be able to figure out a way (whether at runtime or better at static time) to root out "dangling promises", especially of this class:
async function a() {
... do some async operation ...
}
async function b() {
a(); // forgot to call await on it
}
where I have accidentally forget to await on one function and some task that executes asynchronously doesn't get awaited on. Often times these types of bugs don't throw exceptions so I can't just use "unhandledRejection" and call it a day.
At this point after lots of desperate attempts I just need a way to detect this kinda faulty pattern at either (optimally) static/compile/lint time or at runtime. Runtime for me I think should work assuming I have good test coverage.
tl;dr basically, I'm searching for some code that would do something like the following:
Error: Potential dangling promise detected!
...
at b (/dangling.js:5:3)
For each dangling promise
My thought process
I first tried finding some static analysis library that would help to detect these things (theoretically it should be possible but I had no luck with finding such a thing). A while back I remember finding something in the depths of stackoverflow that talked about using some typescript checker to check for dangling promises, though now I can't find it anymore :( . Though at the time changing the entire codebase to typescript was a no-go. (Later I learned you can actually use tsc to typecheck javascript (given that you do some type annotation in comments))
Currently I was previously using node version 11, so I thought about using the node.js's async_hooks API and try to listen on events (apparently simply monkey patching the Promise constructor wouldn't work because node.js bypasses the Promise constructor when creating a Promise object to return from an async function). Using node v11, after a bit of code hackery here it seemed to work (though it's not very efficient cause it throws away a lot of promise optimization in the v8 engine, but it does the job). There was a small hiccup in this entire operation in that I had to still monkey patch the then/catch/finally functions of the Promise API to check if we are currently calling that function (somehow that worked with detecting some dangling promises).
Now enter node v12 (apparently I need this for certain other things that are breaking), and now that hackery (unsurprisingly) completely breaks. After scrutinizing the version diffs, seems like they optimized the await/async implementation. After narrowing down the reason, it seems like await no longer calls the then function of the promise and just directly does some native shenanigans (idk what really).
Now I'm actually kinda desperate for some solution (and maybe if Typescript has some way of type-checking these dangling promises, what was the option to enable this check? I know (tested) that tsc doesn't do this by default).

You are most likely looking for the no-floating-promises rule of typescript-eslint

How to deal with dangling promises

Oftentimes I want to call a promise and just let it run asynchronously instead of waiting for it. Like:
... some code ...
fetchMyCount().then(count => {
updateTheUI(count);
});
... more code ...
Now this works great, but oftentimes I don't put a failure handler on the promise because that is pretty onerous for each one. That would be like putting a try {} catch {} on every one of my data fetches.
The problem is, if it fails, it does so silently. It doesn't throw an exception that my window.onerror can get, it doesn't log, it doesn't do anything.
Now I can make a nice wrapper like:
Async(fetchMycount().then(count => {
updateTheUI(count);
}));
which can generically deal with promises, but then I have to remember to wrap each and every async call.
Is there a way to have a top-level handler like window.onerror or a big try {} catch {} wrapper that can catch all un-dealt-with rejected promises so I can log them and make sure they get fixed?

This is a common use case. Your problem is real. In Node, you have process.on("unhandledRejection", ... events which you can use. Sadly, these are not available in browsers yet. Some libraries which are compatible with ES2015 promises offer them and you can use those until native promises get support.
The upside is that support in browsers is coming and browsers will eventually support these hooks.
Currently, I've convinced the polyfill to add it, so if you're using the core-js polyfill you can do:
window.onunhandledrejection = function(e){
// handle here e.promise e.reason
};
Note that this assumes that something is an unhandled rejection if: It's unhandled, and an error handler was not attached synchronously (within a task to be precise).

Exactly for issues like this, I wrote my own utility for writing asynchronous code:
https://github.com/vacuumlabs/yacol/
It does not help you with your existing code, however with newly written code it provides (among many other things) quite advanced error-handling capabilities.
This said, I don't think that "unhandledRejection" / "uncaughtException" events are good (although it's the best node.js natively provides) tools to do proper error handling:
First, you can only attach it process-wide, so it forces you to handle all uncaught errors the same way (unlike with try-catch where you can react differently to errors that originate from different parts of your code)
Second, "unhandledRejection" is called if .catch is not attached to the Promise in the same run of event loop. This may result in false errors being caught; note it is pretty OK to attach error handler to the promise later!

How do I debug promise-based code in node?

I am using Cujo's great When library to provide a Promises/A+ implementation for my Node project, although this question is not node-specific.
Generally, When's great: it lets me write more maintainable, readable code.
However, when my callbacks fail unexpectedly (accessing a property of a null variable, etc), the exceptions are effectively swallowed by When, as seems to be specified by the Promises/A+ spec. Unfortunately, this means I don't get any feedback about the error (other than the callback stops executing at that point). No error type or message, no line number.
To illustrate:
// hypothetical asynchronous database query
database.query(queryDetails).then(function(result) {
var silly = 3.141592654;
silly(); // TypeError: number is not a function!
process(result); // this code is silently never executed
});
I can think of a handful of (unacceptable) ways to tackle this:
providing failure callbacks for every then call (to dump the reason/exception to the console)
wrapping all callback bodies in try-catches
littering the codebase with "landmark logs" ala console.log('I got here 123')
Am I just doing it wrong? Surely I'm not alone in finding the debuggability of promises-based code poor. Is there an obvious solution I'm missing?

Update Sep 2016: NodeJS 6.6.0+ and 7.0+ will warn automatically on unhandled rejections. Run node with --trace-warnings to get reasonable stack traces. Still not as good as what bluebird gives you but a lot better than the situation before.
Ok, so summing up the information from the comments and add some.
There is nothing in the Promises/A+ specification that dictates how to deal with this problem. The specification is about the minimal requirements for good interop between different promise libraries - so one promise library can consume promises created in another and vice versa.
Several libraries solve this problem by including a .done method that explicitly declares the chain has ended, this causes uncaught rejections to be thrown. Libraries like When and Q solve the problem this way. For example if your .then after .query was a .done you'd get a long stack trace.
Newer, less naive implementations of promises like Bluebird solve this problem by automatically figuring out possibly uncaught rejections and logging them out for you loudly. They also give you a hook. When has experimental support for this using the monitor.
As such:
require('when/monitor/console'); // when will now log async rejections used with
// `then` , this is experimental in when.
With bluebird
Promise.longStackTraces(); // Bluebird always logs async rejections but with this
// option it will stitch the asynchronous context stack
// for you in your methods.
ES6 promises' behavior is unspecified on this. There is no explicit requirements on the native implementations with regards to this. However, I know vendors are working on it and I'd expect engines to start figuring this out even in native implementations.

Here is how I detect when a Promise has been rejected on Node but not caught:
if (typeof process === 'object') {
process.on('unhandledRejection', (error, promise) => {
console.error("== Node detected an unhandled rejection! ==");
console.error(error.stack);
});
}
In addition to that, you could use this monkey wrapper to provide long stack traces for Node's ES6 Promises. It produces similar output to Q's longStackSupport. I would not recommend it for use outside of development code, due to performance concerns. (It's working for me in Node v4.4.1. I have not yet tested it in Chrome or Firefox.)

What's the advantage of returning exceptions over using try catch blocks in async callback chain?

After looking at Twisted's Deferred class and HeavyLifters Deferred Library I noticed that errbacks are fired if the previous resultant value was an instance of the Failure class. This got me thinking: is there any particular reason for returning a special object to denote an error instead of just throwing an error.
From what I deduced I feel it's better to throw errors because:
Any value can be thrown.
If the value thrown is not caught, it propagates up the call stack.
There's no need for a special Failure or Error class.
It makes the callbacks look more like synchronous code.
The exception may be handled at any level of the call stack.
Some of the disadvantages I noticed were:
Trying blocks of code and catching error may cause a performance hit to the code.
If an exception is not caught then it stops the execution of the rest of the callback chain.
Asynchronous programming is essential the polar opposite of using try catch blocks.
I'm trying to weigh the odds and figure out which method of reporting errors is more suitable in this scenario.

The Failure class in Twisted has a number of handy methods that make it useful, independent of the features in Deferred for running error handling callbacks. Browse the API documentation and you'll find useful methods, for example for formatting tracebacks and checking exception types. Failure is also a handy place to put some really gross hacks for getting nice integration with generators for twisted.internet.defer.inlineCallbacks and for special support code for Cython which generates subtly different exceptions.
Failure is also a good place to keep the traceback state together with the exception. Python exceptions normally don't carry stack information, so if you only have an exception, you can't find out where it was raised. That can be a major drawback any time you want to handle an exception outside of the except block that caught it.
Finally, being able to return a Failure enables this simple, commonly useful pattern:
def handleOneErrorCase(reason):
if not thisCaseApplies(reason):
return reason
handleThisCase(reason)
someDeferred.addErrback(handleOneErrorCase)
This frequently shows up in Deferred-using code. It's convenient, happens to be a bit more performant on CPython, and also has the advantage that the original stack information in reason is preserved (if the exception were re-raised by the error handler, the stack at that point would replace the original stack, obscuring the original cause of the exception).

Errors are usually returned with callback in an async environment as errors cannot be caught outside the async function. For example in javascript if you try:
try {
setTimeout(function() { throw new Error(); }, 0);
} catch (e) {
console.log('Caught it.');
}
Then the exception will go uncaught. This has to do with the fact that async functions are reregistered and then later called by the event loop in a different stack and as such the exception won't bubble up the original stack.

How do I debug my asynchronous, promise based code if the library is swallowing all the exceptions?

The Problem
JSFiddle:
http://jsfiddle.net/missingno/Gz8Pe/2/
I have some code that looks like this:
var d = new Deferred();
d.resolve(17);
return d.then(function(){
//do some stuff...
})
.then(function(){
var obj = a_funtion_that_returns_null_on_IE();
var x = obj.some_property; //BOOM!
});
The problem is that when I am on IE all I can see are 'obj' is null or not an object errors, without any reference to the corresponding line number and without the debugger halting at the offending line (like I wish it would).
This kind of issue is making the code a pain to debug and the only solutions I can think of right now (messing around with the control flow library or resorting to step-by-step debugging with the debugger or console.log) are things I would rather not have to do.
What I think is going on
In order to allow errbacks to be added after the chain is fired, then will preemptively catch any exceptions thrown by the callbacks. I think this is the reason for the IE debugger not halting on the error or showing the usual error message witht the line number in it.
The error messages without the line numbers are coming from the control-flow library: it provides a deferredOnError hook that is called whenever an exception is caught and saved for later and the default behaviour is console.error-ing the Error object:
dojo.config.deferredOnError = function(err){
//a chance to log the exception after it is captured by "then"
//or do other things with it
console.error(err);
}
Sadly, I could not figure out a way to get the line number or stack trace from the error object in IE and the hook is called in a way that does not allow me to just rethrow the exception and let it bubble up to the toplevel.
What I want
I want to have a better way to debug the async code then goind along with the debugger step-by-step. In the best case a way to have the debugger halt on the exceptions (as it does on unhandled exceptions) or at least a way to get line numbers or stack traces from the Error object that was thrown.

This works with any framework without prior configuration and all recent browsers support this.
Pause On Caught Exceptions: This will actually stop javascript's execution and will take you exactly where the problematic code is, as it's happening.
In Chrome:
Developer Tools,
Sources tab,
Pause on exceptions (stop-like icon) and then
the Pause On Caught Exceptions checkbox

What I ended up doing
I added a sequencing function to my mini library of async helper functions. It basically runs a sequence of "then" calls, except that it adds extra intermediate steps to rethrow any exceptions that end up being caught by the Deferreds. It also accepts an optional error handler to catch the exceptions.
When I call it it looks like this:
go([
function(){
return 17;
},
function(x){
//return some stuff
},
function(){
var obj = a_function_that_returns_null_on_IE();
var x = obj.some_property; //BOOM!
}
], function(){
//an optional error handler
});
Another reason that I did things this way is that I have lots of code that needs to work simultaneously with either sync or async code (using Deferred.when to do the chaining). Using my custom function let me use a single, unified syntax and the errors not being captured in the async case is consistent with the sync case, where there are no Deferreds involved. I also think its OK to not capture the error, since unlike in the general case, when I am using "go" I know a-priori what code will be called, so there is no need to capture exceptions for if someone needs to catch them in the future.
Also, using a custom solution gave me the freedom to enforce some personal design preferences :)
In addition to that, I ended up reducing the amount of exceptions I generate myself throughout the code base. Managing exceptions in async code is more annoying then usual and sometimes its simpler to just fallback into handling error conditions by returning null or an error code.
Also, we made sure that any exceptions that we create ourselves are instances of the builtin Error class, intead of other objects. The reason is that the builtin Error class records the line number and stack trace of where it was generated in a kind of cross-browser way.

2016 solution
If you're using native ES Promises do absolutely nothing; Chrome automatically reports uncaught promise rejections in the console.
Notice how the caught one (Second fail) doesn't show anything but the uncaught rejection appears in the console after the code is done running.