Throwing vs returning errors?

Throw it. But I haven't used Go yet.

return error || return success || return object
throw exceptions
yield async

Errors == !Success

@FrodoSwaggins not that your opinion matters in this question

Returning error: "sorry, I've had enough beer for today."

Throwing: *just vomit right into the living room*

Throwing. Tho use only checked exceptions at the api layer. Make a use of different kinds of exceptions.

@Fast-Nop
That was the best thing I've read today.

@Fast-Nop that’s exactly how it works. Because you can’t check everything, use try/catch for the unknown stuff.

I never saw a code return an error wtf?

How would this even work in typed languages?
readFile(): string | IOError | OutOfMemoryError | NoAccessError | ...
Have fun handling that shit.

Try/catch might be bad design but i mean there is a whole language made out of syntax sugar (c++), so where does it begin, where does it end, code should be readable.

Unix c handles errors interesting, by returning -1 or NULL and setting errno accordingly. But i mean that's a different world.

@bkwilliams Of course you can. Or the language, library or framework that you are using should.

@nitwhiz Easy: the type could have some sort of "valid" property.

Short answer: Depends on your language. Stick with the accepted conventions, regardless of your preferences, otherwise you'll be branded a massive arsehat by whoever has the misfortune of maintaining your code next.

Is it client-server? Throw an error.

Is it an api? Return an error.

As a big golang user, screw throw. Ever since I started with using multiple returns for errors, my code is drastically cleaner. Throw encourages just wrapping huge sections of code in throw instead of really thinking about control flow.

@FrodoSwaggins I remember seeing an article in which it was recommended throwing vs returning for python. There it was argued that performance boost in returning is not significant for python.
Can't say about other languages.

Why would you say throwing is less maintainable? Returning and checking seems to be a more clusterfucked approach. Can u give example?

@Fast-Nop that's crazy, a byte extra for every return value?

@FrodoSwaggins how about you don't give examples for how bad try/catch is, show me how readFile and it's errors should be made/called without throwing errors and without having "the callback hell" as it is called in js.

@nitwhiz
Depends on the language:
Rust:
The Result-enum is actually a union as an algebraic data-type.
Its has the states "Err" and "OK".
You then match to Result against these two states and destructure the contained data to get your successful return, or your error.

Go:
Go has multiple return-values.
If something may go wrong, and additional return value "err" of the "error" interface is added.
You check if "err != nil", which means something bad happened and then decide what to do with the error.

Other languages:
Tuples:
You can return a tuple, containing the result and the error.
This essentially boils down to the Go-method.

@FrodoSwaggins I didn't get the meaning of well defined flow control.
Tracing all the returns and tracking the error seems more complex than just throwing and then writing a handler for the entire program 🤷‍♂️

@metamourge well that actually sounds neat but it's built into the engine there. But i think doing this tuple thing in something like java would create an unreadable and slow mess.^^

While I’m more of a “catch and deal” style programming, C# 7.1 has support for what @FrodoSwaggins and @metamourge are talking about https://docs.microsoft.com/en-us/... it allows for
public (int? ret, string err) function()

Which I can see as being helpful.

@FrodoSwaggins nah, not js, any language.
readFile should simply read all file contents. How do i design this thing to handle success and give me a string and tell me about io/outofmemory/access/... errors?

@FrodoSwaggins you are absolutely right but you see what massive overhead this tuple thing would create in things like game(engine)s?

@FrodoSwaggins wait a sec, that first approach is fucken genius, never thought of that.

But wouldn't it be pretty messy to keep an errorcode value floating around in every function being set randomly inbetween?

@nitwhiz why is that crazy? For languages that have garbage collection and runtime type detection, efficiency obviously doesn't matter anyway.

@FrodoSwaggins nice to know.

I always thought try catch works like setting an interrupt or let's say signal, called/emitted when doing throw. Because that'd be fast and optimizable (i guess).

@rEaL-jAsE
This could be the first time, your DID is actually useful for me.

@rEaL-jAsE
Dissociative identity disorder,
Because of all your accounts.

@FrodoSwaggins i do cpp right now and had to think of you.

How do I handle errors in constructors?

My specific case is a constructor which opens a file and creates a memory map for it (so 2 calls can go wrong here)
My best guess is a parameter int *success which is going to hold 0 or -1?
But then I can't early return and just stop at the first error.

@FrodoSwaggins makes sense. If e.g. open fails, it makes no sense to really handle it's error but to exit the whole thing as it isn't able to work without the opened file nonetheless. Thanks.

UPDATE: Try in golang has been declined. It will not become part of the standard library

@Techno-Wizard
YES,YES oh fucking YES.