Hacker News Reader

This is a fundamental issue with multitasking, in that an independent task will have its own stack, so errors can't propagate up the stack of the function that started the task.

e.g. consider this python code:

    def start_task():
      Thread(do_task).start()

What happens if do_task throws an exception? The exception can't propagate up from start_task because start_task may have returned when the exception is thrown.

At some point you have to join your threads, and you have to await/then your promises, otherwise there's no well defined place in your program for the exception to go.

Linters can help with this. tslint is one example, I believe it can give a warning for unhandled promises.

`p` will reject, any function that awaits p will reject. The error is that you've fired off an asynchronous task but you don't have any code that cares about the result of that asynchronous task (and the stack of any code that

> otherwise there's no well defined place in your program for the exception to go.

I don't see the problem with that. Unhandled exceptions can occur at any place of your program.

I also don't see why the unhandled exception from the background thread cannot terminate main thread. Why not? That is how unhandled exceptions are supposed to work. Terminating the program is the optimal default behaviour for any error in my opinion. This way you won't miss them.

Your philosophy of error handling composes poorly :)

> I also don't see why the unhandled exception from the background thread cannot terminate main thread. Why not? That is how unhandled exceptions are supposed to work. Terminating the program is the optimal default behaviour for any error in my opinion. This way you won't miss them.

This is how unhandled promise rejections will be handled in node soon. In the browser, you can declare an event handler for unhandled promise rejections.

In Go there are two ways you can handle wrong things happening:

  - return an error
  - panic

What is the recommended, best, pretty, beautiful way? Return an error. Nobody uses panic.

Javascript Promises are equivalent to that.

If you want to stop the main program, call process.exit(). That would be the equivalent of panic.

I don't think it is beautiful. This fills program with lots of unnecessary `if`s for checking results of each call. Also, it prevents one from chaining functions like a(b(x)).

Yeah, you're right. Not beautiful and prevents chaining. But works like a charm, don't you think?

Chaining functions is for functional people. Go is proudly imperative.

If you want to have a specific point to catch an exception, you could write something like this:

    def start_task():
        thread = Thread(do_task)
        thread.set_error_handler(SpecificErrorType, handler)
        thread.start()

Yes, but this has a natural analogue in promise land:

    function startTask() {
      const promise = doTask();
      promise.catch((e) => {
        if (e instanceof SpecificErrorType) {
          handler(e);
        } else {
          throw e;
        }
      });
    }

The difference is the default behaviour: whether errors are fatal or whether they are ignored by default.

Erlang's links http://erlang.org/doc/reference_manual/processes.html#id8861... are an interesting approach to this problem of failure signalling in a concurrent system. Stack-oriented exception handlers certainly don't work properly with concurrency.

Two Erlang processes (~actors) can be linked together. If one then crashes (uncaught exception), the other one is automatically killed - unless it takes special steps to "trap exits", in which case it is sent a message describing the failure in its linked peer.

> While it is expected that the runtime error would float up and terminate the program

This will supposedly happen in a future version of node. [1]

[1]: https://nodejs.org/dist/latest-v8.x/docs/api/deprecations.ht...

It will happen. Most likely Node 11 I'd estimate - 10 seems a little close for landing it

https://github.com/nodejs/node/pull/15126

> This code will just ignore the error. While it is expected that the runtime error would float up and terminate the program - that is what runtime errors are made for.

No, this behavior is consistent with how asynchronous programming works in JS.

    myDiv.addEventListener("click",function(event){
       throw "error";
    });

Nobody would expect that code to terminate a browser tab on error.

> This also makes writing tests more difficult because tests often use exceptions to indicate failure.

Then use async functions, problem solved.

> Nobody would expect that code to terminate a browser tab on error.

That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.

> That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.

No, it has nothing to do with the developer console. It has everything to do with the fact that async exceptions do not bubble up in the main execution thread. Promises work the exact same way since they existed as libraries long before they were included in the language. It's about consistency, nothing more, nothing less.

He literally talks about the work-arounds you can use to delay the function call in the article, and explains why you would prefer it to be default behavior.

Error handling is annoying, and this is (eventually going to be) fixed in Node.js. In the browser, you can add some listeners: http://2ality.com/2016/04/unhandled-rejections.html

Isn't throwing exception in promise same as calling reject?

The receiver of the promise is the one who should handle rejection. Not the one creating the promise.

If the receiver doesn't handle it you can register global error handler and log all unhandled errors.

This is a known footgun of promises. But if you are using async/await, uncaught error in the promise chain is the same as uncaught error inline.

Then the promises should have been advertised as a part of async/await syntax. But many articles promote using them by themselves.

Promises existed way before they were put in the specification and way before async/await. So no, promises could not have been advertised as part of async/await since they came before async/await.