Earlier quoted context omitted.
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.
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 E…
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.