5 ms·

It's been several years since I've used Java, but from what I remember most devs rarely catch unchecked exceptions (like out of bounds access) in their code.

masklinn 6y ago
You generally wouldn't want to catch any random exception you don't specifically know you should or need to catch, as that way lies the madness of working with corrupted data. Usually you'd have a toplevel handler as a final line of defense, but of course that doesn't help if the software automatically restore the state which makes it crash, then you just get a crash loop.
- fiddlerwoaroof 6y ago
  There is another way: Common Lisp and smalltalk both have resumable exceptions (although they’re more limited in smalltalk): in an interactive environment, if the exception isn’t handled, you drop into a debugger that lets you pick a recovery strategy. If something like this were standard on phones, you wouldn’t get stuck in a boot loop and Android could provide the option to enable dev mode or check the internet for a solution.
  - DaiPlusPlus 6y ago
    You can configure a JVM to pause whenever an exception is first-thrown and prompt to attach a debugger. Same with the CLR. I think Windows lets you do it with any program that uses SEH too.
  - SilasX 6y ago
    Yeah but to most users, getting some cryptic console they can implement a workaround in ... isn’t much better.
    - fiddlerwoaroof 6y ago
      It doesn’t need to be cryptic, a screen that says something like “enable dev mode” “attempt to fix from computer” (along with a desktop program for modifying settings) “check for updates” “reset to defaults” would be friendly enough
  - _emacsomancer_ 6y ago
    (In a better world, Android was written in Common Lisp.)
    - pjmlp 6y ago
      Newton almost had it.
- londons_explore 6y ago
  Visual basic had an "ON ERROR RESUME NEXT" feature, which would simply ignore all exceptions and keep running code. Obviously, when one thing goes wrong in a program, frequently that leads to other things going wrong, but IMO thats better than crashing the whole process. Sure, you might get unexpected output, but for many usecases, unexpected output is better than no output at all.
  - akx 6y ago
    Except maybe healthcare or finance or nuclear plant management software...
    - perl4ever 6y ago
      Turning off exceptions in this case doesn't prevent you from handling errors. You just have to check the error object to see.
      - the_af 6y ago
        No, this is not what the person who mentioned ON ERROR RESUME NEXT is arguing. They are arguing in some cases it's better if the program plods along and produces any output, even wrong output, rather than crashing. I think the post above explains why this isn't the case in mission critical software. I'd argue the lesson from software engineering is that it's not advisable in most situations, not just for nuclear reactors. The error was raised by a reason, after all. I'd say it's the opposite: there are some limited cases where you absolutely know the exception is not relevant, and in those cases you can knowingly swallow the exception.
        perl4ever 6y ago
        They stated that the feature "would simply ignore all exceptions". It allows you to ignore all exceptions, but you don't have to and probably wouldn't in most cases. It was an example of blaming a tool for a hypothetical misuse that is not the only way you can use it.
- ufmace 6y ago
  It makes sense to catch any exception in certain specific places. For example in this case, wrap the entire batch of code for loading the file, parsing and processing it, and displaying on the screen in a try-catch in whatever code builds and displays the wallpaper. Then if anything goes wrong, you can log the error, and do some sane recovery steps such as removing that wallpaper and reverting to some default wallpaper that you know is good.
- wutbrodo 6y ago
  The solution is, at every layer of the system, to think about what it means to recover from a failure. In this case, the obvious answer to a failed wallpaper rendering is to avoid rendering the wallpaper, not to allow the failure to bring down the entire UI with it. I didn't always have this habit, but picked it up when I switched from working on servers to working on safety-critical hardware. It was a lot easier a habit to pick up than I thought it would be, and I've found it makes you write a more robust, well-understood system.
  - lioeters 6y ago
    That's good advice, to always be vigilant about how a system would recover from a possible error/failure, at every layer. I imagine this is a discipline that a software developer or engineer learns from experience, by running into edge cases, weird bugs, corrupted state, crashes, etc. It's quite a responsibility on the human side of software. Handling unexpected errors is a pretty easy thing to miss, for programmers who are inexperienced or have become too comfortable (not paying attention to every detail). I can't help but think that the language or compiler (or tests, I suppose) could enforce this better, so that it forces the programmer to explicitly handle recovery from failures - at certain layers/thresholds - so that the error doesn't bubble up to the top and bring the whole thing down. As you pointed out, an error in the UI layer shouldn't have been allowed to trigger a system crash loop. But, that's kind of the nature of bugs like these, they creep in through unexpected logic paths. In which case, the development environment needs to better enforce the (explicit) behavior of all possible paths that an error could take. Well, I'm sure that's constantly improving, as a perennial challenge of reliable software, and there will always be a need for discipline and attentiveness by the humans involved.
    - wutbrodo 6y ago
      > But, that's kind of the nature of bugs like these, they creep in through unexpected logic paths Sure, agreed, this isn't a post-hoc "what an obvious bug, they should have just <done everything perfectly from the start>". I was just addressing the dichotomy laid out by the GP comment, which only mentioned top-level generic exception handling instead of case-specific, intelligent exception handling.

masklinn 6y ago

You generally wouldn't want to catch any random exception you don't specifically know you should or need to catch, as that way lies the madness of working with corrupted data. Usually you'd have a toplevel handler as a final line of defense, but of course that doesn't help if the software automatically restore the state which makes it crash, then you just get a crash loop.

fiddlerwoaroof 6y ago
There is another way: Common Lisp and smalltalk both have resumable exceptions (although they’re more limited in smalltalk): in an interactive environment, if the exception isn’t handled, you drop into a debugger that lets you pick a recovery strategy. If something like this were standard on phones, you wouldn’t get stuck in a boot loop and Android could provide the option to enable dev mode or check the internet for a solution.
- DaiPlusPlus 6y ago
  You can configure a JVM to pause whenever an exception is first-thrown and prompt to attach a debugger. Same with the CLR. I think Windows lets you do it with any program that uses SEH too.
- SilasX 6y ago
  Yeah but to most users, getting some cryptic console they can implement a workaround in ... isn’t much better.
  - fiddlerwoaroof 6y ago
    It doesn’t need to be cryptic, a screen that says something like “enable dev mode” “attempt to fix from computer” (along with a desktop program for modifying settings) “check for updates” “reset to defaults” would be friendly enough
- _emacsomancer_ 6y ago
  (In a better world, Android was written in Common Lisp.)
  - pjmlp 6y ago
    Newton almost had it.
londons_explore 6y ago
Visual basic had an "ON ERROR RESUME NEXT" feature, which would simply ignore all exceptions and keep running code. Obviously, when one thing goes wrong in a program, frequently that leads to other things going wrong, but IMO thats better than crashing the whole process. Sure, you might get unexpected output, but for many usecases, unexpected output is better than no output at all.
- akx 6y ago
  Except maybe healthcare or finance or nuclear plant management software...
  - perl4ever 6y ago
    Turning off exceptions in this case doesn't prevent you from handling errors. You just have to check the error object to see.
    - the_af 6y ago
      No, this is not what the person who mentioned ON ERROR RESUME NEXT is arguing. They are arguing in some cases it's better if the program plods along and produces any output, even wrong output, rather than crashing. I think the post above explains why this isn't the case in mission critical software. I'd argue the lesson from software engineering is that it's not advisable in most situations, not just for nuclear reactors. The error was raised by a reason, after all. I'd say it's the opposite: there are some limited cases where you absolutely know the exception is not relevant, and in those cases you can knowingly swallow the exception.
      - perl4ever 6y ago
        They stated that the feature "would simply ignore all exceptions". It allows you to ignore all exceptions, but you don't have to and probably wouldn't in most cases. It was an example of blaming a tool for a hypothetical misuse that is not the only way you can use it.
ufmace 6y ago
It makes sense to catch any exception in certain specific places. For example in this case, wrap the entire batch of code for loading the file, parsing and processing it, and displaying on the screen in a try-catch in whatever code builds and displays the wallpaper. Then if anything goes wrong, you can log the error, and do some sane recovery steps such as removing that wallpaper and reverting to some default wallpaper that you know is good.
wutbrodo 6y ago
The solution is, at every layer of the system, to think about what it means to recover from a failure. In this case, the obvious answer to a failed wallpaper rendering is to avoid rendering the wallpaper, not to allow the failure to bring down the entire UI with it. I didn't always have this habit, but picked it up when I switched from working on servers to working on safety-critical hardware. It was a lot easier a habit to pick up than I thought it would be, and I've found it makes you write a more robust, well-understood system.
- lioeters 6y ago
  That's good advice, to always be vigilant about how a system would recover from a possible error/failure, at every layer. I imagine this is a discipline that a software developer or engineer learns from experience, by running into edge cases, weird bugs, corrupted state, crashes, etc. It's quite a responsibility on the human side of software. Handling unexpected errors is a pretty easy thing to miss, for programmers who are inexperienced or have become too comfortable (not paying attention to every detail). I can't help but think that the language or compiler (or tests, I suppose) could enforce this better, so that it forces the programmer to explicitly handle recovery from failures - at certain layers/thresholds - so that the error doesn't bubble up to the top and bring the whole thing down. As you pointed out, an error in the UI layer shouldn't have been allowed to trigger a system crash loop. But, that's kind of the nature of bugs like these, they creep in through unexpected logic paths. In which case, the development environment needs to better enforce the (explicit) behavior of all possible paths that an error could take. Well, I'm sure that's constantly improving, as a perennial challenge of reliable software, and there will always be a need for discipline and attentiveness by the humans involved.
  - wutbrodo 6y ago
    > But, that's kind of the nature of bugs like these, they creep in through unexpected logic paths Sure, agreed, this isn't a post-hoc "what an obvious bug, they should have just <done everything perfectly from the start>". I was just addressing the dichotomy laid out by the GP comment, which only mentioned top-level generic exception handling instead of case-specific, intelligent exception handling.