4 ms·

Interfaces would work fine here as well.

• klabb3 5y ago
  As someone who is greatly in favor of composition over inheritance, I don't agree - or at least my experiences don't point that way. Both Rust and Go have had medium sized warts and/or boilerplate around errors, especially if you need control flow to depend on the error. In Python I've never felt that way. Not sure I can put my finger on it, because any trivial example would be fine in either paradigm. I think it has to do with the forced/unnatural upfront decision "is this error a type or an interface" that may change later on, as a type might need to be refactored to an interface. There's probably one or two other reasons I can't think of right now.
  • jatone 5y ago
    flow control is always impacted by errors. rust and go just don't hide that on you with a giant 'go to random location in the stack' capability.
  • Zababa 5y ago
    Standard ML and OCaml have both sum types (like in Rust) and exceptions. I feel like both have their value, and both are important. A nice thing is that you can match on exceptions: match number_of_lines_of_a_file() with | x -> x [ exception File_not_found -> 0 This makes it really easy to create alternative versions of functions, using exceptions or option types: match number_of_lines_of_a_file_opt() with | Some x -> x | None -> raise File_not_found match number_of_lines_of_a_file_exc() with | x -> Some x | exception File_not_found -> None