3 ms·

Some examples of fallback behavior where I don't think exceptions would help that much. * Of two arguments to a function, exactly one is supposed to be non-nul

Some examples of fallback behavior where I don't think exceptions would help that much. * Of two arguments to a function, exactly one is supposed to be non-null (since they're different ways of specifying the same thing). If both end up being non-null, assertAndContinue and just use the first one and pretend the second is null. * When listing all items of type X in a folder, ask the server for all items and do an integrity check that they are indeed in that folder and have the expected type. If any items aren't like that, assertAndContinue and filter those items out and just display the valid ones.

wvenable 8y ago
Wow, I'd definitely throw in both those cases. If someone passed a value to the first function and it ignored it, they're likely not getting the result they want which will propagate through the system and be even worse than just dying right there. Same with the second case.
- alangpierce 8y ago
  To be clear, both are considered bugs and both are reported to our error reporting system as bugs that we will then investigate as if they were crashes. The question is whether it's better to immediately crash the page for the user or whether to proceed in a best-effort way. From our experience, it's very common that the crash is in an area of code unrelated to the primary set of actions the user is trying to take. Having some widget behave strangely in the corner of your screen is much less damaging than completely blocking the user from getting work done. Also, to be clear, both of these examples are in frontend code, where mistakes are very unlikely to cause lasting problems, since anything affecting data integrity would already need to go across the client-server boundary.
  - wvenable 8y ago
    Front-end code (or a desktop app) is a bit different because you don't crash out in front-end situation. But I'd still throw and stop the current function/process and recover at a higher level than let the code continue to run. The user shouldn't be stopped from doing anything else or trying again.
  - temac 8y ago
    If the effects are merely limited to a widget behaving weirdly, this is a sound strategy. And this seems to be the case for front-end code in well designed systems.

wvenable 8y ago

Wow, I'd definitely throw in both those cases. If someone passed a value to the first function and it ignored it, they're likely not getting the result they want which will propagate through the system and be even worse than just dying right there. Same with the second case.

alangpierce 8y ago
To be clear, both are considered bugs and both are reported to our error reporting system as bugs that we will then investigate as if they were crashes. The question is whether it's better to immediately crash the page for the user or whether to proceed in a best-effort way. From our experience, it's very common that the crash is in an area of code unrelated to the primary set of actions the user is trying to take. Having some widget behave strangely in the corner of your screen is much less damaging than completely blocking the user from getting work done. Also, to be clear, both of these examples are in frontend code, where mistakes are very unlikely to cause lasting problems, since anything affecting data integrity would already need to go across the client-server boundary.
- wvenable 8y ago
  Front-end code (or a desktop app) is a bit different because you don't crash out in front-end situation. But I'd still throw and stop the current function/process and recover at a higher level than let the code continue to run. The user shouldn't be stopped from doing anything else or trying again.
- temac 8y ago
  If the effects are merely limited to a widget behaving weirdly, this is a sound strategy. And this seems to be the case for front-end code in well designed systems.