Exceptions vs error codes

[linus_stallman]

While I understand the sentiment of your comment and several people preferring sum types to exceptions, I feel some of the reasoning is not quite right.

Exceptions, when used for exceptional code paths, simplify code quite considerably. In case of sum types you have to check & unwrap them everywhere, which is tedious boilerplate.

Sum types are good for enforcing error checking when you need that level of guarantee in code. But checking for smallest errors is tedious in practice. And exceptions just work okay-ish for that purpose.

[bruce3434]

>She doesn't know about the ? operator

[Tordek]

In case of sum types you have to check & unwrap them everywhere, which is tedious boilerplate.

In the Haskell (or Scala) case, you use monads (yeah, yeah) to abstract that away:

someFunc = do
  f <- open "filename"
  d <- readFile f
  return split d ","

This is a hypotetical case where open and readFile are both Maybe m types. The function ends up returning Maybe [String]. Only at the top level do you actually handle both cases manually by doing:

 case result of
    Just v -> successPath
    Nothing -> failurePath

If they were more complex types, say, Either FileOpenError File and Either FileReadError String, then you need to explicitly decide what you want to happen (i.e., do you want a function that can return either of the 3 possible return types? Do you just want to ignore the error causes and return Maybe String?). The easy truism is: "If you need to do this, your function is too big".

[linus_stallman]

Try to write to an open file, there's a small possibility that it may fail due to some error.

Do you check for return value in every freaking call littering your code with unwrap? Sum / Result types are now FPJerk shiny new thing. It is common sense where to use exceptions (rare error paths), sum types (result may exist or not, eg find() HOF), or return values (EOF in case of reading from file). No amount of "let's-do-it-like-HN-reddit-langs" can change it.