Year of our lord 2018

As opposed to return thingThatReturnsErrors(), which of course rigorously individually handles each type of error.

Most decent devs know that exceptions should only be used in exceptional circumstances. Having to have every function that allocates memory deal with heap exhaustion both violates DRY and make it impossible to write simple and clearly defined functions.

itt

Attached: 1531460113529.jpg (700x963, 94K)

>Most decent devs
So, 0.01% of devs then?

>use function
>compiler can't tell you it throw an exception and neither does the documentation

>every parrot on the planet repeat: "GOTO IS HARMFUL, GOTO IS HARMFUL, GOTO..."
>but they use mechanism worst than GOTO in all aspect.
>break the program flow in unmeaningful ways
>often fly under the radar until something goes wrong

God tier: Pure code without any form of potential or side effect (not for humans)

POWER GAP

Demi-God tier: Not handling errors, user should read the code and understand it's flow even if it contains 50.000.000.000 lines (not for humans)

POWER GAP (human realm)

Top tier: Rust Result, methods and macros (?, panic!, unwrap, expect, etc...). Based compiler saving you from yourself.
Good tier: Go "~Muchi Muchi Panic x Error-code-kun, Magical Girl Adventure~"
OK tier: Straightforward Coherent Custom Error Management System (aka a custom Framework, see various C libs: Sqlite3, SDL, etc...)

POWER GAP

Retard tier: GOTO error handling.

POWER GAP

WTF AM I DOING HURR HURR TIER (You): try... catch... throw...

they are in a different domain, morons.

anyway just use fucking rust.

Try and catch is shit

Exceptions make writing correct code impossible. When anything is capable of breaking control flow, you can't properly clean up resources.

>you can't properly clean up resources.

not really an issue in a gc langauge since most of the resources you speak of will be memory that will be handled automatically.

>"concurrent" language
>garbage collector
go was a mistake

Monads (promises) are the perfect error handling tool. They allow you to handle errors at any time, while still enforcing proper handling at some point and keeping language semantics intact.

I'm writing my website in golang, its pretty good.

Exactly like how you handle errors in C.
Funny how we wasted so much time and energy during all these years when the answer was in front of us for the last 46 years.

i like go for the standard library/emphasis on streams but the lack of continuations has made me write statements like
select {
case some arbitrary channel that would've been an exception:
default:
*recurse*
}

can be annoying but the language simplicity makes it worth it when it's not smart to use something else.

Or maybe its for people that need to make applications scale and dont want to waste their time with a language that would require far more time effort to get the same result that runs a little faster. Goroutines are brilliant and manage themselves so you dont have to spawn and keep track of threads.

Don't hire retards in the first place and you're good with C++.

int main() {
try {
run();
}
catch ErrorLol {
printf("Something... Something wrong, desu desu~");
return 1;
}

return 0;
}

Le C/C++ good code man.

Why are people so against exceptions? It's a very standard tool in python

c++ is a shoddy language. it's implicitly unsafe. ie if your code contains a race condition you can even get junk code being executed. with go and green processes you don't have this concern.

It does not matter how competent the dev is , it will take more time in c++. With golang you put go in front of a function name and it will now execute asynchronously and concurrently if you add channels. This is far easier to make and maintain , lots of large companies use golang for tasks where scale matters.

Because exceptions are sneaky in every API you use and you can't check there is one unless you read the doc (the horror!), and sometime even in the doc they aren't mentioned. Error should be part of your return """"type"""", period. That's what people did in C and that's what people are doing again with Rust and Go. Exception are shits.

Exception are flow breaking often undocumented side effect. That's why they suck more cocks than a Rust programmer.

ie java's burdensome exception behaviour. it can be a useful tool though for control flow internally.

though it can work. with an open type style approach ie ml.

go has no errors

That is not proper C nor C++
>pajeet using exceptions for control flow

>it can be a useful tool though for control flow internally.
Consider a different career

>just return null lol
truly a next gen language

you fucking permazoomers are fucking dumb as shit. never written a map statement before that needs to short circuit but don't want to write a function for it? literally the easiest thing to declare a exception type inline and make it leave scope immediately after.

Do you even know the implications of using exceptions?

>mfw I catch all and return null
don't give a SHIT why ur fag method failed

Attached: lmoayy.gif (127x189, 770K)

lay it on me why continuations are inherently bad when they simplify interface design

>That's what people did in C and that's what people are doing again with Rust and Go. Exception are shits.
except that rust's approach is a little more pragmatic than go in that a similar situation is applied to null values (values are either some or none and some cannot be null without unsafe code) but also rust provides really powerful pattern matching similar to scala and other languages meaning that you won't see retarded code like this in rust,
>if error != nil && error == filepath.ErrBadPattern {

holy shit I think im the guy they replaced you with. either that or there's more of you fags than I thought there'd be

>Go is literally for the pajeets who think C++ is "too complicated".

no, it's for companies with tons of outsourcing that think that even C#/Java are too complicated for Pajeets.

Attached: pop.png (1155x2119, 361K)

Working with other people has me in the mindset that a good programming language shouldn't trust developers. Interestingly enough Go has forced various patterns that quickly let me know something can be refactored to be better, but also allows me to gauge someone elses level of expertise, not just with the language itself, but programming as a whole.
The difference in seeing how people define their apis, handle errors, etc.

You can have this in other languages but it's not usually so clear cut. With Go you can see it instantly. And better yet, you're not in for any surprises from an incompetent team member.

>I abuse the language because it's easier to write and syntactically legal :)
worst

>2018
>try/catch is good exception handling

Attached: 1499449425949.jpg (450x340, 20K)

>abusing
dumb retard. how do you abuse a language which provides these features for that reason?

>I've done it my whole life, that makes it okay
lmao

foo, err := bar()
if err != nil {
//...
}

Is it really that hard user? Are you retarded?

C# confirmed pajeet

Required reading for everyone, even non-Go programmers.
blog.golang.org/errors-are-values

I love Go

>syntactically correct
try functionally correct you absolute spud. what language do you write on the day to day?

did you forget your meds, schizo

Attached: facepalm.jpg (546x566, 52K)

What difference does it make? arbitrary jumps are a legal method of flow control too, but that doesn't mean your program is good by any metric. Exceptions should not be used for flow control, that's amateurish.

it's a perfectly valid way to simplify the interface for your code.
ie
let exception Short of in
try

What a kludge, I can't believe people treat this as a benefit of their language.

>Abusing a feature because it's easier
In 10 to 20 years from now someone else is going to have to maintain your code, they'll come up against what you just described and then spend the next few hours/days trying to work out what the fuck you were trying to do. Once they've worked it out it'll become the laughing stock of the office until the next fuck-up comes along.

I know this to be true, because part of my job is maintaining other peoples legacy code. On behalf of the people that will have the unfortunate job of maintaining your code, I want to tell you.
>We hate you.

and that's a good thing!

>group of brainlets who've never heard of continuation style programming

shit coders (you) who probably work with a language with implicit side effects should hate themselves first

The keyword here is group, it's obvious that you've never worked in one.
>my shit on paper is a masterpiece, I don't care what anyone else says

Sure you can write things however you want, that doesn't mean it's maintainable or good.

>shit coders (you)
>From the guy using exceptions to control flow
lol, give this a read senpai.
en.wikipedia.org/wiki/Self-awareness

Please respond

Attached: sicily_map06.jpg (504x333, 23K)

yes. it looks as retarded as doing if ((x = some_failing_call) < 0) { // err stuff } in C

exceptions are a much better way of handling real faults since they bubble up as well instead of silently pass through if you forgot to check for an error condition that may or may not ever actually happen.

errors and exceptions are different stuff. C doesn't handle exceptions, C++ and Java thinks everything is an exception, Go does it right.

>never written a map statement before that needs to short circuit but don't want to write a function for it?

solution: don't use a map func if you want to only iterate over a few items in the collection. what the fuck is wrong with you retard? you're literally throwing an exception for a literal non-error?

try catch is nigger tier coding

i would avoid it as much as possible.

why? because you can have the compiler tell you that a call to function can throw and you don't handle it? sounds a lot superior to allowing users to write shitcode that isn't resistant to possible errors.

>C shart is more popular than Java
Interesting...

math/rand.NormFloat64()

please leave the industry

>managing memory for a concurrent application
good luck, I'm sure your university assignment is proof it can be done!

this.

If you're going to do exceptions, Common Lisp's signal system curb-stomps every competitor. Otherwise, exceptions make code horribly unreadable. In Go, it's easy: any call to a function that can return an error must check for an error. This way, any reader immediately understands where an error originates from and where it is handled.

dude just use sum types lmao

What are you talking about?

When an exception happens, it's usually related to IO - those resources will not be released in all languages. Enjoy your 10,000 open file descriptors.

What is try with resources?
What is finally?

even python has some RAII shit like with blocks and as said.

Fucking based as fuck. Holy shit I've never seen such a perfect representation of "programmer power levels". You must be close to demi-god tier, user.

stop replying to your own posts. it's retarded just like you.

Go is strictly inferior to erlang in every way

go back to work rob

Attached: 1511725296074.png (838x855, 449K)

You really don't like try catch? Is Jow Forums just being contrarian? Pretty much everyone I know thinks it's useful.

C++ want to get ride of try catch and replace it with the expected. Copying Rust.
Everyone now realize that Try Catch are just GOTO that goes everywhere and nowhere.

The short answer is: Go intends to replace C, not C++.

Go intends to replace C++ by being C for 21. century.

Exceptions are bad. Use sum types. If the language is too primitive to have those, use product types.

For how long have you worked professionally for?

>that millennial zoomer faggot who recommends that we start rewriting things in GO and asks the project manager for funding to pay for training for it

Attached: 1528938633693.png (546x1090, 55K)

isn't that mostly interests by students, or in other words what they have to learn at school

if err != nil {
return
}
Repeat ad nausium.

>no generics
go is pretty much java from 20 years ago how the FUCK can you excuse using this garbage

Try-catch is for people who write error prone code.

you literally can't. it's inferior to even java in almost all ways except for some niche meme concurrency features.

This.

>compiled to native code and statically linked binaries with no dependency hell.

>small, simple, easy to write and understand.

>allows to use pointers but handles unnecessary stuff like memory management.

>...

> NOT java

How does this compare to Go?

Attached: 154862145898745.jpg (850x283, 63K)