There are definitely legitimate use cases for generics, but `if err != nil` isn't one of them. You'll simply be pattern matching on an option type instead. Go generate is definitely not a substitute for generics.
If you have multiple things that can fail in sequence, you can "lift" into option and then the result of your expression will either be a real result or a short-circuited error.
https://drboolean.gitbooks.io/mostly-adequate-guide/content/...
Or just use exceptions. Either would be preferable to C-style error handling.
Hey, look, a monad! \o/
It also communicates exceptions via option types, and - by convention - functions that can go wrong return an instance of Result<SuccessType, ErrorType> initialized either with a success value or an error value.
There are some helper methods on Result. I like "expect", which panics if an error is indicated and returns the success value otherwise. The real boilerplate removal comes via try!, which returns the result (actually it re-wraps it in a new Result) if it's an error. When used on functions that can fail inside functions which return Result, the result is that try! bubbles the exception up the stack.
The experience is very like traditional exception handling, but you always know exactly how control can flow, since try! only returns from the function it is directly inside, and can only from functions which advertise that they can fail by having Result<> as their return type.
How is that different than with error return values?
> Or just use exceptions. Either would be preferable to C-style error handling.
I disagree. Exceptions seem to hide the problem. In Java and Python, I see people consistently fail to handle exceptions properly. The error paths are neglected because exceptions "hide" them. I would rather have a correct program with verbose error handling than a program that only has an elegant happy path but is otherwise incorrect.
Compare: https://gist.github.com/nickretallack/1462f2652cda6fc2a97283...
If you can find a way to improve these code samples, please suggest it.
> Exceptions seem to hide the problem.
I haven't used Java in a while, but I recall a feature where it would force you to handle exceptions. It knows what kind of exceptions a function can throw, and it can check if they are exhaustively handled throughout the program.