Why can't the brainiacs at Google figure out one of the most basic and fundamental things for a programming language, error handling? C# figured it out years ago. What's the whole commotion with Go Lang failing to give their users proper error handling?

>>105566595 (OP)
Show me how it's broken? I never had any issues.

>>105566602
Remember when gotards argued for 15 years that generics were le bad then go devs came out and admitted they screwed up by not including them? Good times.

>>105566662
Well, at least we got the feature, so better late than never

>>105566690
Praying you niggas get exceptions soon

>>105566602
Tx, error := foo(barl
If err = nil { fmt.println('fail')}
If tx.sucess = false {
fmt.print(also a fail that is same same but differnt but you cant put it in err cauae you cant assume the type of tx if it errors)
Txw8gt

>>105566595 (OP)
Go and Rust use basically the same sort of error handling (Rustfags will argue until they day they become a woman that using a result type and checking the state of that type instead of just checking if a value doesn't exist is better but in reality its just semantics) and it's far superior to what other language do. Only Indians like try/catch/raise exception bullshit because it allows them to write code that never checks for failures. Go has problems, like having cancerous iterators or everything being initialized to 0 except types that aren't like some kind of retarded gotcha but it's error handling isn't a problem. Anyone who disagrees with me is objectively wrong and should stick to python and jeetscript for the rest of their lives.

>>105566717
So you want to bundle all your errors into one giant blob of errors? Like some kind of error factory. Interesting.

>>105566793
Tx, err =foo(barp
Err = nil {}
Tx.err =nil {}
If i care about this difference i should be inside foo

>>105566821
Stick to java, you'll be happier.

>>105566595 (OP)
Every error handling solution sucks.

>>105566595 (OP)
>Why Does Go Lang Error Handling Suck?
It doesn't, you're just a nocoder so superficial syntax is all you understand.

>>105566595 (OP)
>C# figured it out years ago.
exceptions are the second worst part about that language (and I like C#)

>>105568527
>>105566776
result type is shilled recently as preferable method of error handling in c#

>>105566717
there is a difference between failing to make a request or the request failing itself. For example calling some API that returns an error over a successful HTTP request. Go makes it easy to differentiate and handle them desu. There is absolutely nothing wrong with "if err != nil", I just wish they added a "?" shortcut for it

>>105570054
this is stupid

i wish people would already realize what "error" is. an alternative return path from function. exceptions just turn that path into a language feature, with added benefits like automatic error propagation, finally blocks, stack traces, seamless function composition etc. everything that go and rust programmers wish for and trying to emulate with various libraries (read https://docs.rs/anyhow/latest/anyhow/ and tell me how it's not a bastardized attempt to emulate exceptions).

for example, there is no difference between
//tuple as error path
(x, err) = foo();
if (err != nil) {}

//out parameter as error path
x = foo(&err);
if (err != nil) {}

//thread static location as error path
x = foo();
if (GetLastError() != nil) {}

//exception as error path
try {
x = foo();
}
catch (Exception err) {}

>>105570844
So you propose wrapping hundreds of lines of code in a big try catch block? Similar to Rust's cuck blocks (unsafe).?

>>105566698
Go has always had exceptions. See panic()/recover()

>>105566595 (OP)
Put if err != nil in a handleErr function.

handleErr(err, "Put this text in a log file")

>>105571163
Oh good for them. I assume a project is underway to rewrite the standard lib to support this superior error handling tool?

>>105566662
remember that blog post where russ cox says that they've been planning to add generics to the language since before 1.0?
good times

>>105570844
>exceptions just turn that path into a language feature
except worse because now you have literally no idea what piece of code can error
which is why go's error handling is actually the best once you stop being a pseudo retard and realize that explicit is better than implicit

>>105566595 (OP)
>C# figured it out
>try-catch-finally
>easier than "if err != nil"
I don't like programs returning when they feel like it. I want it to happen only on "return" statements.
Exceptions are pretty much a "goto" statement that jumps up the execution stack, which is the bad version of "goto".
>>105570844
It's only devs that are switching the from another language. They usually grow out those libraries.