5 ms·

I don't understand how some other language would not need to handle all the errors ? I have written code in go/java/php/python/js and error handling has been a

I don't understand how some other language would not need to handle all the errors ? I have written code in go/java/php/python/js and error handling has been a majority chunk of lines in most if not all cases(in other cases the errors are just not handled). The best ideal case flow is always easiest to build.

macintux 9y ago
You've not yet tried Erlang.
Arcsech 9y ago
I highly recommend that you try out a language with good support for option/maybe types: Haskell and Rust are good options here. Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place. Alternatively, give Erlang or Elixir a shot: their primary mode of error handling is "don't, let it crash", which is possible due to the relatively unique process model.
- raiph 9y ago
  > I highly recommend that you try out a language with good support for option/maybe types Right. Like Perl 6. > Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place. P6 does this stuff particularly well. It makes option types opt out. You have to explicitly specify the equivalents of Just or None, otherwise you're automatically dealing with an option type if you're dealing with a type. Conditional constructs are designed to work well in this context. One can use ML style pattern matching as those conditional constructs. And other styles of matching. Error exceptions are unified with error values, allowing codebase/author A to use one style, and B to use the other but pretend that A's code used B's style, and for C to use B's code in whichever style they prefer, seamlessly promoting/demoting between warnings, errors, and exceptions, including across language boundaries, as fits a use case. And so on. Perl 6 learned from Perl 5 but it also learned from Haskell and many other languages. > Alternatively, give Erlang or Elixir a shot Note that the author of the OP is well known in the Erlang community.
  - Arcsech 9y ago
    How is "opt-out option types" different from, say, Java, where everything is nullable and all the problems that come with that? Honest question, as I haven't had a chance to look into P6 as much as I would like. It looks pretty cool in a lot of ways, but I'm worried that all of the options available would create a confusing mess. > Note that the author of the OP is well known in the Erlang community. Yeah, my comment was directed at the parent who asked: > I don't understand how some other language would not need to handle all the errors ? And was intending to give a brief description of how other languages (possibly including P6, though I don't have the experience to say) handle errors differently from the languages they listed (go/java/php/python/js).
    - raiph 9y ago
      > How is "opt-out option types" different from, say, Java, where everything is nullable and all the problems that come with that? Aiui the Java compiler and language constructs generally don't know the difference. The P6 Nothing isn't a null, it's a "type object" with memory- and type- safe behavior. There's a tiny bit more about this at: https://en.wikipedia.org/wiki/Option_type#Perl_6 https://en.wikipedia.org/wiki/Option_type#Perl_6
digitalzombie 9y ago
> I don't understand how some other language would not need to handle all the errors ? Erlang and it's VM doesn't need error handling (edit: like the ones you listed). You use pattern match and you match for the outcome you want. So every other state is a let it crash and burn cause you don't care. Because of this mentality you don't have to be God and figure out all the possible fail state to Error check. The VM enable this type of thinking because it's preemptive. And also there are supervisor trees to resent your program state. The error check is in form of monitor and robustness I guess but it's not in the usual form of other popular languages like the ones you listed. This is why I prefer Erlang over Go in concurrency. The BEAM VM is good. Also no generics.

macintux 9y ago

You've not yet tried Erlang.

Arcsech 9y ago

I highly recommend that you try out a language with good support for option/maybe types: Haskell and Rust are good options here. Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place. Alternatively, give Erlang or Elixir a shot: their primary mode of error handling is "don't, let it crash", which is possible due to the relatively unique process model.

raiph 9y ago
> I highly recommend that you try out a language with good support for option/maybe types Right. Like Perl 6. > Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place. P6 does this stuff particularly well. It makes option types opt out. You have to explicitly specify the equivalents of Just or None, otherwise you're automatically dealing with an option type if you're dealing with a type. Conditional constructs are designed to work well in this context. One can use ML style pattern matching as those conditional constructs. And other styles of matching. Error exceptions are unified with error values, allowing codebase/author A to use one style, and B to use the other but pretend that A's code used B's style, and for C to use B's code in whichever style they prefer, seamlessly promoting/demoting between warnings, errors, and exceptions, including across language boundaries, as fits a use case. And so on. Perl 6 learned from Perl 5 but it also learned from Haskell and many other languages. > Alternatively, give Erlang or Elixir a shot Note that the author of the OP is well known in the Erlang community.
- Arcsech 9y ago
  How is "opt-out option types" different from, say, Java, where everything is nullable and all the problems that come with that? Honest question, as I haven't had a chance to look into P6 as much as I would like. It looks pretty cool in a lot of ways, but I'm worried that all of the options available would create a confusing mess. > Note that the author of the OP is well known in the Erlang community. Yeah, my comment was directed at the parent who asked: > I don't understand how some other language would not need to handle all the errors ? And was intending to give a brief description of how other languages (possibly including P6, though I don't have the experience to say) handle errors differently from the languages they listed (go/java/php/python/js).
  - raiph 9y ago
    > How is "opt-out option types" different from, say, Java, where everything is nullable and all the problems that come with that? Aiui the Java compiler and language constructs generally don't know the difference. The P6 Nothing isn't a null, it's a "type object" with memory- and type- safe behavior. There's a tiny bit more about this at: https://en.wikipedia.org/wiki/Option_type#Perl_6 https://en.wikipedia.org/wiki/Option_type#Perl_6

digitalzombie 9y ago

> I don't understand how some other language would not need to handle all the errors ? Erlang and it's VM doesn't need error handling (edit: like the ones you listed). You use pattern match and you match for the outcome you want. So every other state is a let it crash and burn cause you don't care. Because of this mentality you don't have to be God and figure out all the possible fail state to Error check. The VM enable this type of thinking because it's preemptive. And also there are supervisor trees to resent your program state. The error check is in form of monitor and robustness I guess but it's not in the usual form of other popular languages like the ones you listed. This is why I prefer Erlang over Go in concurrency. The BEAM VM is good. Also no generics.