4 ms·

I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn'

I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.

jb1991 4y ago
In Swift, at least, the possibility that a function can throw must be marked as part of its signature, and the exception cannot be ignored if it is thrown so the call requires explicit syntax as well, so there is no way to miss that something could "blow up" when reading the code.
- eunoia 4y ago
  It's a little old at this point, but I find the Swift Error Handling Rationale design doc to be absolutely fascinating. It cites other language’s error handling paradigms (including Rust) if you're curious: https://apple-swift.readthedocs.io/en/latest/ErrorHandlingRationale.html https://apple-swift.readthedocs.io/en/latest/ErrorHandlingRa...
  - jb1991 4y ago
    Fascinating, looking forward to reading this later today! Have used a handful of languages over the years, and I don’t have any academic perspective in different error handling techniques, but there’s no doubt that the way swift does it feels particularly natural, safe, but still gets out of your way. I love all the options for handling errors in a meaningful way.
Jensson 4y ago
In Java functions declares Exceptions in its type signature, so it does all of that automatically. Then you get a compile error if you don't handle it in the function, or you need to declare the function throws it, so it is type safe. Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that.
- newZWhoDis 4y ago
  > Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that. What people? Please tell me where they’re at so I can tell them they are wrong (lol) But seriously, I could not disagree more.
  - lenkite 4y ago
    The designers of the Java functional and stream library for one. None of the functional contracts have throws. So you are forced to have un-checked exceptions for everything, unless you want a truly mind-boggling amount of try-catch everywhere which will rapidly exceed your normal code by factor of 2x-3x.
    - mike_hearn 4y ago
      In Java, yes. Note that the JVM doesn't enforce checked exceptions. It's a language level thing. So in Kotlin for example, where all exceptions are unchecked, you can use the streams library without needing try/catch.
    - PaulHoule 4y ago
      ... or you can just use a sane FP library like https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove Some people don't like the Lispy signatures so I did start coding up a version with with a fluent interface but didn't quite finish. Overall I would say the implementation of lambdas and method references in Java 8 was genius, but the stream library was a big mistake. Part of it is that has this cumbersome API that in principle would let it optimize query execution by looking at the pipeline as a whole but doesn't really take advantage of it.
- jb1991 4y ago
  > Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that. Well, Swift is a much newer language than Java, and exceptions in Swift cannot be hidden either. And some people do rather like this.
taeric 4y ago
I get where you are coming from, but imagine if every other "to the human" process description we had was done this way. I actually think this would be a fun one. How to make scrambled eggs, but where all failure cases are covered. Would be the "Hal fixes a lightbulb" in prose.
- sowbug 4y ago
  That gets to the original promise of computers, doesn't it? That they'd perform repetitive tasks quickly and reliably. Meanwhile, every time I make scrambled eggs, there is a small but very real chance that my house burns down. And we accept this because to err is human.
  - taeric 4y ago
    Sorta? But a lot can be packed away in "other directions." Most recipes, for example, assume that setup/teardown is intrinsic to the kitchen. As such, to know the procedures to do those things, you would look somewhere else. That is, you aren't accepting a risk that things will go wrong. You have moved what to do about many exceptions to somewhere else.
wvenable 4y ago
Assume all functions can throw and there is no extra work reading. A function that has no possibility of error is so uninteresting in the context of error handling. Furthermore, handling errors has little to do with where the error is actually caused. In general, you can only do two things with errors: log and kill the operation or retry the operation. Neither of these has anything to do with the leaf function 20 items down in the stack that actually made the network call that failed.
- sanderjd 4y ago
  What you're describing here are unchecked exceptions, which Rust has in the form of panic. There are other kinds of errors that can be handled closer to the point where they occur.
- erik_seaberg 4y ago
  We have to be deliberate about where we retry, and how quickly. It’s all too easy for layers to create a death ray of n factorial requests.
- nemothekid 4y ago
  If I am in the business of writing robust code; then "assuming all functions can throw" means at the very least forcing every function call to be surrounded by a try/catch block? It almost always make sense to handle an error locally if you can; for example if I want to retry the operation (let's say I'm writing a distributed database client), it may make sense for me to retry another node rather than unwinding to the application level that has now lost all context. >A function that has no possibility of error is so uninteresting that focusing on that is the wrong thing. I spend a lot of time debugging errors in code that has 0% chance of failing. It tends to involve a lot of matrix math. This isn't something you can say is universally true especially given all the hype around AI now.
  - quietbritishjim 4y ago
    > It almost always make sense to handle an error locally if you can This is highly presumptuous. I have written many programs that did not need to handle errors locally, and so exception handlers were only at the very top level (or, actually, just below the top-level usually - but the point is that there were generally few and I had flexibility to decide where to put them). Perhaps you and I write very different applications. But the fact remains that the "almost always" in your statement doesn't hold. Alternatively line of reasoning: if this was always true then there would be little point to Rust's ? as it would be so rarely used.
PaulHoule 4y ago
Exceptions always work the same way. You learn how to read code with exceptions pretty quickly.
- frodowtf 4y ago
  How does an explicit raise operator like '?' work any different than that? You can learn how to read it pretty quickly.
einpoklum 4y ago
You may prefer that, but everyone else who has to read your code - doesn't. Yours is an approach which is likely to ensure your code is discarded and has to be rewritten relatively quickly.

jb1991 4y ago

In Swift, at least, the possibility that a function can throw must be marked as part of its signature, and the exception cannot be ignored if it is thrown so the call requires explicit syntax as well, so there is no way to miss that something could "blow up" when reading the code.

eunoia 4y ago
It's a little old at this point, but I find the Swift Error Handling Rationale design doc to be absolutely fascinating. It cites other language’s error handling paradigms (including Rust) if you're curious: https://apple-swift.readthedocs.io/en/latest/ErrorHandlingRationale.html https://apple-swift.readthedocs.io/en/latest/ErrorHandlingRa...
- jb1991 4y ago
  Fascinating, looking forward to reading this later today! Have used a handful of languages over the years, and I don’t have any academic perspective in different error handling techniques, but there’s no doubt that the way swift does it feels particularly natural, safe, but still gets out of your way. I love all the options for handling errors in a meaningful way.

Jensson 4y ago

In Java functions declares Exceptions in its type signature, so it does all of that automatically. Then you get a compile error if you don't handle it in the function, or you need to declare the function throws it, so it is type safe. Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that.

newZWhoDis 4y ago
> Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that. What people? Please tell me where they’re at so I can tell them they are wrong (lol) But seriously, I could not disagree more.
- lenkite 4y ago
  The designers of the Java functional and stream library for one. None of the functional contracts have throws. So you are forced to have un-checked exceptions for everything, unless you want a truly mind-boggling amount of try-catch everywhere which will rapidly exceed your normal code by factor of 2x-3x.
  - mike_hearn 4y ago
    In Java, yes. Note that the JVM doesn't enforce checked exceptions. It's a language level thing. So in Kotlin for example, where all exceptions are unchecked, you can use the streams library without needing try/catch.
  - PaulHoule 4y ago
    ... or you can just use a sane FP library like https://github.com/paulhoule/pidove https://github.com/paulhoule/pidove Some people don't like the Lispy signatures so I did start coding up a version with with a fluent interface but didn't quite finish. Overall I would say the implementation of lambdas and method references in Java 8 was genius, but the stream library was a big mistake. Part of it is that has this cumbersome API that in principle would let it optimize query execution by looking at the pipeline as a whole but doesn't really take advantage of it.
jb1991 4y ago
> Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that. Well, Swift is a much newer language than Java, and exceptions in Swift cannot be hidden either. And some people do rather like this.

taeric 4y ago

I get where you are coming from, but imagine if every other "to the human" process description we had was done this way. I actually think this would be a fun one. How to make scrambled eggs, but where all failure cases are covered. Would be the "Hal fixes a lightbulb" in prose.

sowbug 4y ago
That gets to the original promise of computers, doesn't it? That they'd perform repetitive tasks quickly and reliably. Meanwhile, every time I make scrambled eggs, there is a small but very real chance that my house burns down. And we accept this because to err is human.
- taeric 4y ago
  Sorta? But a lot can be packed away in "other directions." Most recipes, for example, assume that setup/teardown is intrinsic to the kitchen. As such, to know the procedures to do those things, you would look somewhere else. That is, you aren't accepting a risk that things will go wrong. You have moved what to do about many exceptions to somewhere else.

wvenable 4y ago

Assume all functions can throw and there is no extra work reading. A function that has no possibility of error is so uninteresting in the context of error handling. Furthermore, handling errors has little to do with where the error is actually caused. In general, you can only do two things with errors: log and kill the operation or retry the operation. Neither of these has anything to do with the leaf function 20 items down in the stack that actually made the network call that failed.

sanderjd 4y ago
What you're describing here are unchecked exceptions, which Rust has in the form of panic. There are other kinds of errors that can be handled closer to the point where they occur.
erik_seaberg 4y ago
We have to be deliberate about where we retry, and how quickly. It’s all too easy for layers to create a death ray of n factorial requests.
nemothekid 4y ago
If I am in the business of writing robust code; then "assuming all functions can throw" means at the very least forcing every function call to be surrounded by a try/catch block? It almost always make sense to handle an error locally if you can; for example if I want to retry the operation (let's say I'm writing a distributed database client), it may make sense for me to retry another node rather than unwinding to the application level that has now lost all context. >A function that has no possibility of error is so uninteresting that focusing on that is the wrong thing. I spend a lot of time debugging errors in code that has 0% chance of failing. It tends to involve a lot of matrix math. This isn't something you can say is universally true especially given all the hype around AI now.
- quietbritishjim 4y ago
  > It almost always make sense to handle an error locally if you can This is highly presumptuous. I have written many programs that did not need to handle errors locally, and so exception handlers were only at the very top level (or, actually, just below the top-level usually - but the point is that there were generally few and I had flexibility to decide where to put them). Perhaps you and I write very different applications. But the fact remains that the "almost always" in your statement doesn't hold. Alternatively line of reasoning: if this was always true then there would be little point to Rust's ? as it would be so rarely used.

PaulHoule 4y ago

Exceptions always work the same way. You learn how to read code with exceptions pretty quickly.

frodowtf 4y ago
How does an explicit raise operator like '?' work any different than that? You can learn how to read it pretty quickly.

einpoklum 4y ago

You may prefer that, but everyone else who has to read your code - doesn't. Yours is an approach which is likely to ensure your code is discarded and has to be rewritten relatively quickly.