>>103204062
good op
>captcha: x4 NAG

>>103205395
Just remember every time you see one of these, it's something you're just simply ignoring in your own software. You can ignore the errors by _ them. But then you are a shitter.

>>103204062
I like Go. It's the best choice of the majority of things one could make.

>>103204062
go where?

>>103205850
They're not ignored, they're just handled in clean, organized, structured ways through exceptions instead of being paranoid about each and every little thing that could go ""wrong"" in every single line of code.

>>103205955
It's just obtuse because I handle 99% of errors in the same way.
All I ever want is to display the error, then curl up into a ball and die.

>>103205955
>they're not ignored, they're just ignored

>>103205955
Obviously you can do that if you're aspie by assigning non nil to another variable and catching that at the end of the block.

>>103204062
Me too, I just started using it.
Very simple, nice, fast language.
It's basically like C but with the ease of you of Python.
A lot of the things people complain about with it is what actually makes it good. Ken Thompson understands KISS
And it's much more powerful than people make it out to be. It's subtle simplicity. Not like Lua which is mentally ill simplicity.

>>103205955
>clean, organized, structured ways
Exceptions are none of those things

>>103207204
>cucked by a real failure model
pathetic

>>103205897
This.

>>103205955
I've worked professionally with Go errors, a Go-style explicit errors framework in C++, and exceptions as the sole error handling path in Python and C#. The exceptions were the worst ballache to handle by far. Every time you hit a fun little try/catch block, figuring out the exact code flow that will be executed under various circumstances is a little nightmare. Identifying exactly which line threw a given exception (and for what reasons!) is not always trivial, and then you have to understand which pieces of code did execute before the exception was thrown and which did not. Developers clearly should have been pretty paranoid about the things which could go "wrong" in those lines of code, but frequently weren't even aware that things could go wrong at all. I'm sure it's easier to write for a room temp IQ, but it makes it a lot harder to debug and fix the nightmare code after the fact.

Don't get me wrong. Exceptions are a useful paradigm. I use panic() a lot in my Go code, especially new binaries where I don't have a great reason to avoid >>103206030 as a model for handling various issues. But before I finish a section, I tidy up the panics and create a neat error-based interface - because that makes it far, far easier to use and reuse that code in future.

I can't imagine how retarded you'd have to be to want your dependencies to default to terminating your program when they hit issues, and how cucked you'd have to be to wrap each external call with a try/catch block so you can keep running for nonfatal errors. Why not just have the dependency report an error back to you using a single well-structured pattern?

>>103212650
>Identifying exactly which line threw a given exception (and for what reasons!)
This part is a skill issue. Try blocks should be treated as (optional) if err != nil blocks; that is, they should only wrap the line that could potentially raise an exception and they should only try to catch the exceptions you're looking for.

>wrap each external call with a try/catch block so you can keep running for nonfatal errors
This is also a skill issue. You're supposed to wrap the entry point with a try block in a while loop so you can log uncaught exceptions and continue running the program.

In my opinion, the real problem with exceptions as error handling are the hidden errors that you don't notice while writing and aren't caught at compile time but cause problems at runtime. You could call some function and forget to wrap it in a try block, either through ignorance or carelessness, and then you get runtime errors.

Exceptions work well in Python because it's a toy scripting language and when you're writing a quick script, you want most errors to just kill the program and print out a nice stacktrace. I'll admit, though, that Python code often looks neater than Go code because all those err != nil blocks can get clunky and interfere with readability.

>>103212894
>skill issue
Yeah, I'd rather my programming languages not have patterns that multiple-six-figure FAANG programmers apparently can't handle. Exceptions are the GOTO problem all over again. They make sense as something you CAN do, and indeed are the correct solution for certain problems, but the complexity they add is extremely dangerous for most programs to the point that they shouldn't be the default option.

Otherwise, agreed. Those are good ways of handling exceptions... but they start to look a lot like an informal way of writing Go-style error handling that has no assistance from the compiler in reminding you to do the right thing.

>Exceptions work well in Python because it's a toy scripting language
Wish someone had fucking told the aforementioned multiple-six-figure FAANG engineers before they built 1k to 10k line programs as critical dependencies of our stack.

>>103212894
Less if you do the err on the same line. As in

if err := func(); err != nil {
   return fmt.Errorf("failed to build database: %w", err)
}

}

>>103214225
Only works if you're discarding all other return values from func(). Otherwise, you have to torture variable declarations to get the value outside of the if statement's scope, or wrap the happy path in an else statement.

The extra line for an if statement isn't that bad.

>>103205955
You may not like, but a simple if statement is literally the simplest, cleanest, most organized error handling there is.

>>103216677
It's all well and good until some asshole doesn't export the error he returns.

>>103212650
>Why not just have the dependency report an error back to you using a single well-structured pattern?
This pattern actually has a name -- they're called exceptions.

Are exceptions really considered bad now? C chads... we have won?

File: file.png (12 KB, 612x83)

12 KB PNG

>Gotards

>>103212650
>The exceptions were the worst ballache to handle by far.
And yet it's equivalent to the other ways; it's just different ways to make the same sum type. You should probably give up programming and become a monk or an accountant or some shit like that.

>>103220283
>And yet it's equivalent
So is raw assembly, you dumb fuck

>>103220283
Unfathomably retarded; roughly equivalent of claiming that a GOTO is just a "different way" of making a function call. Yes, I know you did have breakfast this morning.

>>103214452
Well yeah, it's good in some situations like a straight pass fail situation, or if you already declared the othed returns etc so don't have to shadow with := and can just use =