4 ms·

I would assume case B, which isn't really that unique. Erlang for example follows that pattern (and has no concept of "exception"). After all, I/O errors, parsi

I would assume case B, which isn't really that unique. Erlang for example follows that pattern (and has no concept of "exception"). After all, I/O errors, parsing errors, etc., aren't exceptional; they very much should be expected. Forcing them to be handled in the normal code path helps create robust systems. (There are of course also true runtime errors -- e.g. out-of-memory -- and precondition errors -- i.e., coding errors that fall outside the capability of the type system to enforce -- which do not fit this pattern.)

macintux 8y ago
>> The language uses the type system to propagate such errors. ... > Erlang for example follows that pattern. Erlang is its own beast; if you characterize pattern matching as part of a type system, which I guess it is, then...maybe if you squint? Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown...if you're lucky. If the error pattern happens to fit with the pattern match but the code doesn't know about it, eventually some other error will occur. Anyway, Erlang definitely doesn't fall into the "No runtime exceptions, ever" category, and as such doesn't really fit with the options the OP presented.
- colanderman 8y ago
  I think we read the OP differently. I'm just responding to the bit about errors being returned as an "Either" type. You are right that Erlang does not enforce pattern matching to succeed, though its static analyzer (Dialyzer) can catch many instances when it definitely won't.
- dragonwriter 8y ago
  > Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown With a sufficiently complete static (even inferred) type system, you can catch any possibility of such failures AOT and not run into any error patterns that don't match code expectations at runtime, so while the description isn't literally true of Erlang, Erlang does show a way that it could be true of a language with AOT enforcement of adequate type system.
masklinn 8y ago
> Erlang for example follows that pattern (and has no concept of "exception"). Erlang absolutely has a concept of exceptions. They're even called exceptions: http://erlang.org/doc/reference_manual/errors.html#exceptions http://erlang.org/doc/reference_manual/errors.html#exception....
- colanderman 8y ago
  Wow, I used Erlang extensively a few years ago and don't remember exceptions at all. (Exit reasons and process monitors, yes; but I don't think I ever wrote a "catch" expression, or encountered a library that expected me to do so.)
  - masklinn 8y ago
    Yeah it's very rare to catch exception within processes, or to raise them explicitly. It's common to write something like {ok, Result} = foo() though, and that raises badmatch if it fails, and you handle it in a supervisor.
  - rs86 8y ago
    You can use throw/catch to great effect when you need non local returns

macintux 8y ago

>> The language uses the type system to propagate such errors. ... > Erlang for example follows that pattern. Erlang is its own beast; if you characterize pattern matching as part of a type system, which I guess it is, then...maybe if you squint? Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown...if you're lucky. If the error pattern happens to fit with the pattern match but the code doesn't know about it, eventually some other error will occur. Anyway, Erlang definitely doesn't fall into the "No runtime exceptions, ever" category, and as such doesn't really fit with the options the OP presented.

colanderman 8y ago
I think we read the OP differently. I'm just responding to the bit about errors being returned as an "Either" type. You are right that Erlang does not enforce pattern matching to succeed, though its static analyzer (Dialyzer) can catch many instances when it definitely won't.
dragonwriter 8y ago
> Normal errors are indeed typically reflected in the return value, but if the error pattern doesn't match the code's expectations then a runtime exception is thrown With a sufficiently complete static (even inferred) type system, you can catch any possibility of such failures AOT and not run into any error patterns that don't match code expectations at runtime, so while the description isn't literally true of Erlang, Erlang does show a way that it could be true of a language with AOT enforcement of adequate type system.

masklinn 8y ago

> Erlang for example follows that pattern (and has no concept of "exception"). Erlang absolutely has a concept of exceptions. They're even called exceptions: http://erlang.org/doc/reference_manual/errors.html#exceptions http://erlang.org/doc/reference_manual/errors.html#exception....

colanderman 8y ago
Wow, I used Erlang extensively a few years ago and don't remember exceptions at all. (Exit reasons and process monitors, yes; but I don't think I ever wrote a "catch" expression, or encountered a library that expected me to do so.)
- masklinn 8y ago
  Yeah it's very rare to catch exception within processes, or to raise them explicitly. It's common to write something like {ok, Result} = foo() though, and that raises badmatch if it fails, and you handle it in a supervisor.
- rs86 8y ago
  You can use throw/catch to great effect when you need non local returns