5 ms·

By the way I have tried to use promises in PHP (they are almost the same as JS promises) and had the same problem with promises catching all exceptions and repo

By the way I have tried to use promises in PHP (they are almost the same as JS promises) and had the same problem with promises catching all exceptions and reporting nothing. I am thinking now about writing my own version of promises because nobody seems to understand how to handle exceptions and unhandled rejections correctly. > Catching unhandled errors is by design and it works great. I don't think that it's great because by default I would prefer to terminate the application if there is an unhandled error or rejection. This is called "fail fast" principle. What promises developers suggest is to continue running the application even if it's broken.

WorldMaker 9y ago
Tearing down an entire application immediately due to an asynchronous exception has the possibility to leave the system in a deadlock or worse. It's a bad idea in any asynchronous environment. JS isn't today truly asynchronous in most usage today, but they are planning for that future (present if you count Service Workers and Node/Electron).
- codedokode 9y ago
  What you are suggesting (preventing errors from crashing application) only makes discovering errors more difficult. For example, application might look like it is working ok, but some of requests do not return any response or return invalid data - because an exception was ignored. Try googling "fail fast" if you want to see more reasons to use this principle. > Tearing down an entire application immediately due to an asynchronous exception has the possibility to leave the system in a deadlock or worse. It should not. Because application can crash anyway - for example, if there is memory access violation or out-of-memory error. And synchronous applications crash on uncaught exception, I don't see why asynchronous applications should not.
  - WorldMaker 9y ago
    Fail fast is also a terrible user experience: why did my app just disappear, did I do something wrong? It implies blame to users that may not be at fault. Sure, fail fast is very useful in debuggers to help a developer find and fix problems. But this is why we have debuggers. Debuggers are a terrible user experience, we don't need to force every user to live in a debugger and decide themselves which errors matter. Not every exception is "fatal" and "might look like it is working ok" is often good enough in the pragmatic real world where you can't control everything. Also, just because you've never accidentally caused a machine to BSOD on a deadlock or catch fire from an improper halt in a "fast fail" of multi-threaded code, that just means you are one of the lucky ones. There are disastrous consequences to bad multi-threaded code during "fail fast" teardowns of threads not privy/cause to the error. There are enough nightmare scenarios to keep a multi-threaded programmer up at night. I appreciate your concern that developers sometimes ignore errors they should fix instead or handle more appropriately. "Fail fast" in a debugger works to help that. "Fail fast" in day-to-day operation isn't the right solution, at the very least for making users possibly hate you because you'll never properly handle 100% of exceptions.
    - codedokode 9y ago
      I have worked with code (in PHP) that didn't use "fail fast" approach and didn't even log most warnings and notices. App didn't crash but sometimes randomly returned invalid results. Of course, nobody fixed this because after reloading the page the error could be gone. If you ignore errors or warning you just get low quality code as a result. Maybe this code will corrupt your database content, who knows. It is safer to stop the code if something seems wrong. Also I remember reading somewhere that the earlier you find the error the cheaper it is to fix it. > why did my app just disappear, did I do something wrong? Usually operating system reports that there was an error in the application. If the application crashes often, the users will complain to developers and they will fix it. > Debuggers are a terrible user experience, we don't need to force every user to live in a debugger You should test your app properly before releasing it. > There are disastrous consequences to bad multi-threaded code during "fail fast" teardowns of threads not privy/cause to the error. I cannot agree with this. Usually the OS releases all locks, closes all files, frees memory when the process terminates. I don't see what can go wrong here and how you can get a deadlock because some process has terminated. Also if you use locking you should add some kind of timeout. For example, MySQL has lock timeouts and can even detect and fix deadlocks. > "Fail fast" in day-to-day operation isn't the right solution, at the very least for making users possibly hate you because you'll never properly handle 100% of exceptions The users will probably hate you more if the app will silently hang or show incorrect data.

WorldMaker 9y ago

Tearing down an entire application immediately due to an asynchronous exception has the possibility to leave the system in a deadlock or worse. It's a bad idea in any asynchronous environment. JS isn't today truly asynchronous in most usage today, but they are planning for that future (present if you count Service Workers and Node/Electron).

codedokode 9y ago
What you are suggesting (preventing errors from crashing application) only makes discovering errors more difficult. For example, application might look like it is working ok, but some of requests do not return any response or return invalid data - because an exception was ignored. Try googling "fail fast" if you want to see more reasons to use this principle. > Tearing down an entire application immediately due to an asynchronous exception has the possibility to leave the system in a deadlock or worse. It should not. Because application can crash anyway - for example, if there is memory access violation or out-of-memory error. And synchronous applications crash on uncaught exception, I don't see why asynchronous applications should not.
- WorldMaker 9y ago
  Fail fast is also a terrible user experience: why did my app just disappear, did I do something wrong? It implies blame to users that may not be at fault. Sure, fail fast is very useful in debuggers to help a developer find and fix problems. But this is why we have debuggers. Debuggers are a terrible user experience, we don't need to force every user to live in a debugger and decide themselves which errors matter. Not every exception is "fatal" and "might look like it is working ok" is often good enough in the pragmatic real world where you can't control everything. Also, just because you've never accidentally caused a machine to BSOD on a deadlock or catch fire from an improper halt in a "fast fail" of multi-threaded code, that just means you are one of the lucky ones. There are disastrous consequences to bad multi-threaded code during "fail fast" teardowns of threads not privy/cause to the error. There are enough nightmare scenarios to keep a multi-threaded programmer up at night. I appreciate your concern that developers sometimes ignore errors they should fix instead or handle more appropriately. "Fail fast" in a debugger works to help that. "Fail fast" in day-to-day operation isn't the right solution, at the very least for making users possibly hate you because you'll never properly handle 100% of exceptions.
  - codedokode 9y ago
    I have worked with code (in PHP) that didn't use "fail fast" approach and didn't even log most warnings and notices. App didn't crash but sometimes randomly returned invalid results. Of course, nobody fixed this because after reloading the page the error could be gone. If you ignore errors or warning you just get low quality code as a result. Maybe this code will corrupt your database content, who knows. It is safer to stop the code if something seems wrong. Also I remember reading somewhere that the earlier you find the error the cheaper it is to fix it. > why did my app just disappear, did I do something wrong? Usually operating system reports that there was an error in the application. If the application crashes often, the users will complain to developers and they will fix it. > Debuggers are a terrible user experience, we don't need to force every user to live in a debugger You should test your app properly before releasing it. > There are disastrous consequences to bad multi-threaded code during "fail fast" teardowns of threads not privy/cause to the error. I cannot agree with this. Usually the OS releases all locks, closes all files, frees memory when the process terminates. I don't see what can go wrong here and how you can get a deadlock because some process has terminated. Also if you use locking you should add some kind of timeout. For example, MySQL has lock timeouts and can even detect and fix deadlocks. > "Fail fast" in day-to-day operation isn't the right solution, at the very least for making users possibly hate you because you'll never properly handle 100% of exceptions The users will probably hate you more if the app will silently hang or show incorrect data.