4 ms·

There is still a problem that some sites will have a service worker and some will not. Maybe it would make more sense to allow the user to pick what they want t

There is still a problem that some sites will have a service worker and some will not. Maybe it would make more sense to allow the user to pick what they want to cache for offline reading. > The service worker fetch event is a promise, By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way [1]. [1] https://stackoverflow.com/questions/28001722/how-to-catch-uncaught-exception-in-promise https://stackoverflow.com/questions/28001722/how-to-catch-un...

untog 9y ago
> There is still a problem that some sites will have a service worker and some will not. Why is that a problem? > By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way If you're using promises there is really no reason to not be handling your errors. Catching unhandled errors is by design and it works great. It's absolutely trivial to do. And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Promises might not be perfect, but they're better than JS callback hell in absolutely every way.
- codedokode 9y ago
  > And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Why make a new non-standart event instead of just throwing an error and handling it with default error handler? That is poor design - because initially there was no reporting of unhandled errors at all and only later a workaround was added.
  - WorldMaker 9y ago
    `window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.
    - codedokode 9y ago
      If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.
      - WorldMaker 9y ago
        Browsers have a long backwards compatibility story to deal with and the interplay of synchronous errors and the synchronous error event is a part of that. Just because you don't see a need to introduce a new event doesn't mean bright minds didn't think about it.
- codedokode 9y ago
  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.

untog 9y ago

> There is still a problem that some sites will have a service worker and some will not. Why is that a problem? > By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way If you're using promises there is really no reason to not be handling your errors. Catching unhandled errors is by design and it works great. It's absolutely trivial to do. And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Promises might not be perfect, but they're better than JS callback hell in absolutely every way.

codedokode 9y ago
> And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Why make a new non-standart event instead of just throwing an error and handling it with default error handler? That is poor design - because initially there was no reporting of unhandled errors at all and only later a workaround was added.
- WorldMaker 9y ago
  `window.onunhandledrejection` is a part of the spec, it simply took a bit for browsers to catch up to it. It's a different handler because an application may need to know the difference between a synchronous error and an asynchronous error and handle them (dramatically) different.
  - codedokode 9y ago
    If there is a need to distinguish between different kind of errors then it can be done by checking error prototype (if (error instanceof AsyncError) { ... }). There was no need to introduce a new event. I think the reason is because some developers have a kind of exception-phobia and they prefer to hide errors (make developer check for them explicitly) rather than let them bubble up. I see this in other platforms too. For example, in .NET if a background thread crashes because of unhandled exception then nothing happens to the main thread, no error is reported. The developer must check for an error and of course most developers won't care about this. Another example is how error reporting is done in a browser. JS errors are never shown to the user so if a rich JS app has an error the user won't know about it, the app will just stop working or show invalid data.
    - WorldMaker 9y ago
      Browsers have a long backwards compatibility story to deal with and the interplay of synchronous errors and the synchronous error event is a part of that. Just because you don't see a need to introduce a new event doesn't mean bright minds didn't think about it.
codedokode 9y ago
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.