In sync programming if your function does the wrong thing you typically get an error thrown or you get a result which you check for its correctness.
But when you call an async-function that is supposed to do something like say write to a file or database maybe there is an error which makes it never do its job, and never call the callback you gave it. But the rest of your program just hums along happily. There is no error. The error does not "happen" but the error is that "something did NOT happen". And when something does not happen you don't get an error or notification saying that something did not happen.
You run your program but expected results do not show up in database. But you don't know why, because the problem is that some of your async functions did NOT call something they should have called.
It's hard to detect that something does not happen.
Some kind of built-in support for callback-timeouts might alleviate this problem.
What are you talking about? if you're async operation fails then your callback should always still be called but just with an error message in the second parameter typically. And what are you doing still giving call backs to async functions? Why are you not using promises?
I think previous poster is talking about a bug where the promise is never resolve nor rejected. So it just hangs out there, unresolved, forever.
I don't think using explicit callbacks helps, though, which has the same potential issue (worse really, since you're probably handling callbacks directly more often, depending on the patterns you use).
Right. Except I was able to experiment with a wrapper-function which set up a timeout on the callback which threw an error if the callback was not called within a set interval of time.
It helped to detect some flaws in my program.
A similar thing could no doubt be done with promises. But I think the best solution would be if there was a built-in facility to detect callbacks that were not called within a required or default time interval.
Eventually I stopped using the timeout wrapper, it didn't help very much, but made the code more complex. More but easier to understand code is often my preferred choice.
Whereas if language itself offers built-in facilities then fine since they are more likely to be bugfree than my own code.
Javascript code doesn't just stop executing for no reason, if the callback needs to stop executing, it should reject the promise or throw an error. Or resolve with an error value. That's like saying "in sync programming, if you don't check for error conditions, your code continues humming along happily just the same".
If there is an error when reading a file or accessing a database, unless the file or database API is horrendously designed, it will reject the promise or throw.
> Javascript code doesn't just stop executing for no reason,
I would say it stops unless there is something keeping it running.
Think about your single-page-web-app. When you click on some widget on it a click-handler triggers and executes that code. But then it stops. When the user doesn't interact with your web-app no JavaScript is typically executing, unless you have set up a repeating polling loop with setInterval().
The scenario you described is a classic one and I really don't think it's as problematic as you may think. I had to reread it because it sounded too trivial. How about just throwing an error when the async function fails to write to the db?
>maybe there is an error which makes it never do its job
You can throw an error regardless of the reason why it failed to do its job. If the write to the db does not success, you can throw an error.
You are supposed to call fs.write() etc. But you do it only under certain logical conditions. Those logical conditions do not arise like you would expect because of logic errors elsewhere in your code.
So your async function never calls fs.write() even though it was your intention that it should. Is that an error? Definitely, the file was never written to, it now has wrong content. But the problem is, as you run your program you do not get any error thrown at you, therefore you don't even know there is a problem. Later on you may, or may not, realize that the content of the file is wrong. And then it's hard to say what caused that error.
What "caused something not to happen" is a difficult question to answer because you can't pinpoint the exact location in time and code where it did not happen. Why? Because it did not happen anywhere, ever :-)
Btw this same issue exhibits in python with threads. If you spawn an async computation in a thread and an uncaught error is raised, the thread disappears silently, leaving you with a callback that’s never called or a future that’s never resolved.
But I assume in a thread-based language like Java all asynchronicity happens due to threads. Then from the programmers' point of view method-calls always either return a result or throw an error. They don't just silently stop executing
>One thing that is tricky with async is that nobody tells you if the async function never does what it should
Could you clarify this?