231–240 of 425 posts
Personally, I feel that the motivation for the issue is one of convenience. The most common use case is changing the flow control in the event of an error to return from the current stack. I'm not a fan of defining an error handler. This seems far too intrusive and cumbersome and a bridge too far. GoLand gets around this somewhat by adding in the Live Template of "err" being a macro expansion for the if err != nil {…
Earlier quoted context omitted.
try errors in elixir: with {:ok, val1} handle_notfound_error() {:error, :eperm} -> report_permission_error() _ -> raise("don't worry this process is supervised, let it crash!") end low cyclomatic complexity makes for a nice user experience, and you learn the philosophy of "if it doesn't work, just turn it off and on again". Why be scared? Just let it go. The VM has your back.
What's the equivalent in elixir for something like this? func do(a Param) (res Result, err error) { var aPrime T if aPrime, err = getResource(a); err != nil && err == RecoverableError { aPrime = definitelyNoErrorAlternativeGetResource(a) } var aPrimePrime T ... // many more steps return doSomething(aPrimePrimePrime) }
you can manage it a few ways in Elixir, struct matching is one:
def perform(param) do
res =
case get_resource(param) do
{:ok, val} -> val
{:error, %RecoverableError{alternative_value: val}} -> val
end
do_more_things(res)
endEarlier quoted context omitted.
"But Rust has no equivalent of handle: the convenience of the ? operator comes with the likely omission of proper handling." what's that supposed to mean? The ? operator just bails out if an Error result is returned from the called function, and forwards that Error to the caller. Cleanup is performed implicitly by drop implementations (destructors) using the RAII pattern ala C++.
In the draft design, they give an example of special-case cleanup that would only execute only when an error occurs , not on the success path. You can emulate this with a boolean flag in your RAII types in Rust or C++, that's set or cleared immediately before a successful return, and then doing conditional logic in your Drop/dtor. Or you could do a std::mem::forget before successful returns. But I guess they think th…
I think Go sometimes swings too far in the simplicity direction, not letting consenting folks choose to use shorthand, but that’s a very valid design decision.
Earlier quoted context omitted.
> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that…
I don't think folks are on 2.7 because they love it. I think they're there because it's difficult and expensive to migrate Python code.
Earlier quoted context omitted.
>So long as we can all agree that it feels super bad, I guess this is fine. Actually, I don't think everyone agrees it feels super bad. I personally like having all of my error handling be explicit, painfully explicit even. >approaches the Java world back with checked exceptions where principle trumped ergonomics. I also have to disagree here. To me, checked exceptions are the worst of both worlds. Here you have addi…
> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them. Like: I dislike it because it does the opposite, it makes it too easy to accidentally continue execution when there is an error: doThing(); // Error doOtherThing(); Which isn't possible with Exceptions. The only thing that would signal that error handling is missing is the absence of boilerplate to handle…
Earlier quoted context omitted.
> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. Personally I enjoy writing Go code similar to the way that I enjoy writing Python code. So they did something right because I wouldn't ever say the same about Java or PHP. Edit: As a fun tangent... Python experienced the same kind of fracturing that…
pg wrote a bunch of really good essays about Java vs Python vs Lisp and how those were perceived by programmers. I always remember them when I see Go being compared to Java while still being liked by Hackers. I wonder what he would write about this phenomenon.
Earlier quoted context omitted.
> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting…
>There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. Object thing1; try { thing1 = doStuff(); } catch(SameException e) { // handle error 1 } try { return doOtherStuff(thing1); } c…
doOtherStuff(doStuff())
Earlier quoted context omitted.
I guess then I have to ask, why would try() make that worse? Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced. On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be conf…
Try makes it worse because it is so easy to miss when reading the code. Because it encourages nesting function calls, which is harder for a human to parse than separate statements across lines. Because it means you can exit the current function from the middle of a line of code, and what runs before or doesn't run before is based on order of operations rather than requiring the exit to be a statement on its own line…
I absolutely agree. Beyond the human parsing aspect it also makes commit changes easier to reason about and review. I want functionality to be limited per-line and view the ability to combine a lot of functionality into one line as a liability more than a benefit.
Go's error handling isn't carefree or hands-off, but that's because error handling is serious. Especially in network code and cryptography.
Earlier quoted context omitted.
> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…
I understand what you mean by “bad ergonomics”, but I think of those things as “ergonomics in the small”. You end up writing for loops and error checks. It’s verbose but not complex, and it’s all very localized. Further, people get really hung up on these small language issues and miss go’s killer features: simplicity and consistency. Go is a small, simple language with few surprises. No guesswork about which feature…
That's also why I think Go will forever be a "to each his own" language. By targeting that lowest common denominator, choices are made for you, some people will always dislike it, and others will always love it.
This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software. If it ain't brok…
Typing “if err != nil { return nil, err }” a million times is not thought.