7 ms·

> error passing is via try/catch, which is the best error handling pattern we've figured out so far The best error handling pattern for scripts we've figured o

> error passing is via try/catch, which is the best error handling pattern we've figured out so far The best error handling pattern for scripts we've figured out so far, but at the same time the worst error handling pattern for systems known to man.

brabel 2y ago
I disagree. I write very large code bases in Kotlin and Java. Kotlin did away with checked Exceptions and it's a pleasure to use, without any significant decrease in the quality of the systems compared to Java, quite the opposite because Kotlin forces you to check stuff like nullability. I've also used Rust and I simply can't see any real improvement in the reliability of code I've written just because it forces you to use Result type (it's just too easy, and tempting , to swallow an Error or panic with `unwrap` because otherwise you just end up with every single function returning Result, making it really non-egornomical to work with... arguably the Rust language itself did that with arithmetic operators).
- randomdata 2y ago
  It seems you agree. Systems and scripts are not differentiated by the size of the codebase. The way you speak about errors, like "being tempted to swallow errors" and "returning Result from every single function", suggests that you are accustomed to writing scripts. Which isn't unexpected as a lot of computing workloads are script in nature. And, indeed, the 'try/catch' model is well suited to it. But it not fun when writing systems. That is why we have different tools for different jobs.
  - brabel 2y ago
    Your definition of "script" is completely different from what most people would use and honestly makes no sense.
    - randomdata 2y ago
      That's fine. Obviously words can mean anything and naturally one would ensure that they are aware of what they are intended to mean in a given context before going any further if there is any lack of clarity. As there was no earlier questioning of what they might mean, there clearly was no issue with clarity. To backtrack now is strange and hilarious. But I posit that the "definition" is consistent with the literature. Scripts carry out a defined set of tasks and if something goes wrong they can simply fail, wait for the problem to be resolved, and then try again. Systems don't have the same luxury. They have to find alternative solutions when fault occurs. "An error occurred. Try again later." is not acceptable for systems, but is acceptable and perfectly valid for a large class of computing problems. Again, "try/catch" is great for scripts as most of the time you just want the error to "bubble up to the top" to notify the user, or whatever, anyway. Such a thing would be unthinkable in systems, though. When you actually have to deal with errors at every turn, "try/catch" is a slog, and I would argue a poor mental model to boot (what's special about errors that deserves something different?). It turns out that software development is an engineering endeavour, not a religious one. Different tools for different jobs.
      - brabel 2y ago
        I suppose you live in a bubble where "script" is almost all code ever written. Here's a definition of "script" that shows how out-of-touch your definition is: https://en.wikipedia.org/wiki/Scripting_language https://en.wikipedia.org/wiki/Scripting_language "... a script is a relatively short and simple set of instructions that typically automate an otherwise manual process." You keep talking about "system" as if there was also a clear definition for that in software, which makes me think you're not even a software engineer at all, are you? > Obviously words can mean anything No, that's your mistake. Words can't mean what you choose they to mean! Do you know the old meme "Stop trying to make fetch happen!"?? So, "system" wont' happen! I guess that you're talking about embedded development??? Where Exceptions are not used because they're a bit too costly (and because they're written in C which has an incredibly primitive error handling, it doesn't use Result types anywhere), NOT because they make software unreliable. You may disagree with that, but for goodness sake stop with your condescending tone pretending that you know something you clearly don't and work on "systems" which we, mere mortals (despite you having zero idea what kind of "systems" I work on), have no idea about.

brabel 2y ago

I disagree. I write very large code bases in Kotlin and Java. Kotlin did away with checked Exceptions and it's a pleasure to use, without any significant decrease in the quality of the systems compared to Java, quite the opposite because Kotlin forces you to check stuff like nullability. I've also used Rust and I simply can't see any real improvement in the reliability of code I've written just because it forces you to use Result type (it's just too easy, and tempting , to swallow an Error or panic with `unwrap` because otherwise you just end up with every single function returning Result, making it really non-egornomical to work with... arguably the Rust language itself did that with arithmetic operators).

randomdata 2y ago
It seems you agree. Systems and scripts are not differentiated by the size of the codebase. The way you speak about errors, like "being tempted to swallow errors" and "returning Result from every single function", suggests that you are accustomed to writing scripts. Which isn't unexpected as a lot of computing workloads are script in nature. And, indeed, the 'try/catch' model is well suited to it. But it not fun when writing systems. That is why we have different tools for different jobs.
- brabel 2y ago
  Your definition of "script" is completely different from what most people would use and honestly makes no sense.
  - randomdata 2y ago
    That's fine. Obviously words can mean anything and naturally one would ensure that they are aware of what they are intended to mean in a given context before going any further if there is any lack of clarity. As there was no earlier questioning of what they might mean, there clearly was no issue with clarity. To backtrack now is strange and hilarious. But I posit that the "definition" is consistent with the literature. Scripts carry out a defined set of tasks and if something goes wrong they can simply fail, wait for the problem to be resolved, and then try again. Systems don't have the same luxury. They have to find alternative solutions when fault occurs. "An error occurred. Try again later." is not acceptable for systems, but is acceptable and perfectly valid for a large class of computing problems. Again, "try/catch" is great for scripts as most of the time you just want the error to "bubble up to the top" to notify the user, or whatever, anyway. Such a thing would be unthinkable in systems, though. When you actually have to deal with errors at every turn, "try/catch" is a slog, and I would argue a poor mental model to boot (what's special about errors that deserves something different?). It turns out that software development is an engineering endeavour, not a religious one. Different tools for different jobs.
    - brabel 2y ago
      I suppose you live in a bubble where "script" is almost all code ever written. Here's a definition of "script" that shows how out-of-touch your definition is: https://en.wikipedia.org/wiki/Scripting_language https://en.wikipedia.org/wiki/Scripting_language "... a script is a relatively short and simple set of instructions that typically automate an otherwise manual process." You keep talking about "system" as if there was also a clear definition for that in software, which makes me think you're not even a software engineer at all, are you? > Obviously words can mean anything No, that's your mistake. Words can't mean what you choose they to mean! Do you know the old meme "Stop trying to make fetch happen!"?? So, "system" wont' happen! I guess that you're talking about embedded development??? Where Exceptions are not used because they're a bit too costly (and because they're written in C which has an incredibly primitive error handling, it doesn't use Result types anywhere), NOT because they make software unreliable. You may disagree with that, but for goodness sake stop with your condescending tone pretending that you know something you clearly don't and work on "systems" which we, mere mortals (despite you having zero idea what kind of "systems" I work on), have no idea about.