6 ms·

doesnt every mainstream language panic (or undef behavior) on out of bounds array access? explicit error returns is a little clumsy, but still nicer than excep

• spullara 6y ago
  Many threaded languages throw an exception that can be caught and if not caught, kills that thread. Not the whole program. See Java, C#, etc.
  • Thaxll 6y ago
    If not cought you end up in a really bad state.
    • recursive 6y ago
      If you don't catch it, you generally don't end up in a bad state. More like a lack of a state altogether.
    • apta 6y ago
      Any well-written framework will have a base-level exception handler. If not, it will simply exit the program with a trace. Compare that with actually ending up with bad state in golang if errors are accidentally ignored or overwritten (I've seen it happen several times). golang errors are strictly inferior.
  • stickfigure 6y ago
    And in practice, with Java, C#, etc programs, there's a high level catch that prevents anything terrible from happening. Http requests return 500, UI threads show an error dialog, etc. In almost all business processing, thanks to the magic of transactions, you never end up in a bad state.
    • spullara 6y ago
      The one thing that I don't think either has tackled is that things like OOM can leave synchronized blocks in a bad state. There are certain errors which should kill the whole process which is why they have the flag that lets you do that. But for more mundane errors, you have an escape hatch.
  • dilap 6y ago
    That's the same as Go panic's tho. (Go panics are extremely close to exceptions: the only difference is they can only be caught at function boundaries instead of scope boundaries.) The main difference is cultural: you're encouraged to use return codes for expected error conditions and only panic for program bugs. But there's the temptation to not do that because panic(/exceptions) are more ergonomic. I think exceptions tend to be OK in areas where you don't really care about handling errors: eg command-line tools, GUIs. But for long-lived proccesses, like servers, where it's important to handle errors in a precise way, they are painful, in my experience.
    • freeone3000 6y ago
      Not really. There's a root exception type, which is caught by any framework worth its salt to prevent the scenario described above from breaking program flow for other executing fibers.
      • dilap 6y ago
        Hmm, I think it's the same still. Go doesn't have type heirchies, but you can "catch" (recover in Go parlance) any panicked value. It's exactly equivalent, no?
        • apta 6y ago
          To an extent, but you end up getting the worst of both worlds (and then some). You end up having to "catch" panics at the handler level anyway, and end up with verbose and very error-prone error handling in the code.
          • dilap 6y ago
            I'd disagree, personally. I much prefer the explicit error-handling style of Go, even if I also have to handle panics. Errors are explicit; panics (which are program bugs, and can't be handled) are implicit. But program bugs are always implicit. To put it more concretely, my experience has been it is easier to write correct code using the error return style of Go than the exception style of Python or C#. (And though I sadly haven't had an opportunity to use them for "real work," the explicit-error-return-with-ergonomic-syntax regimes of Rust/Zig/Haskell seem even nicer.)
  • to11mtm 6y ago
    Slightly pedantic point: In the case of C#, not observing an exception (i.e. catching or thrown by another thread could kill the whole program before .NET 4.5. But this was pretty easy to guard around in various, even easy (if sloppy) ways.
• 1-more 6y ago
  Elm (not mainstream, I concede) wraps list and array access in a Maybe (aka an Option if you're more familiar with ocaml) so there's no throwing or erroring when you try to get what's not there. Kinda pleasant.
  • dilap 6y ago
    intersting. how's that work out in practice? seems like it could be clumsy. e.g. what does binary search look like in elm? in general i always thought out-of-bounds controlled-crashing seemed the program was a reasonable thing to do, since it's arguably a bug in the program, not an error in input. or what about integer oveflow? or divide by zero, it would seem very impracticle indeed to wrap all those operations in maybe...
    • TylerE 6y ago
      In languages with pattern matching (which I assume Elm has, although I've never used it personally, it's very natural. A portion of a binary tree walk in pseudo-code might look something like match (s.left){ with Some x -> recurse(s.left) Nothing -> pass } Basically the difference is that it forces you to deal both branches (In a typical pattern match, you either need to explicitly handle all subtypes, or have some sort of catch-all/default case) and it makes sure you can't call the "do something" branch when you actually have nothing.
      • dilap 6y ago
        Right, but that's for a context where None is a natural value. Have array access return maybe would be much less convenient. What would binary search look like? How about integer division? How about addition, which might overflow? Modeling all possible failures as maybe seems like it would be clumsy...
        • mpalmer 6y ago
          Returning a Maybe for an array access captures the context of possible failure inherent in that operation. Not handling it doesn't make it go away. Luckily, languages with parameterized types (Maybe being one) let you write generic code to handle Maybes. You might be envisioning overly nested conditionals, but languages more or less avoid this