// ???

Catch e throw e. Catch e throw e. Catch e throw e.

Lets play pong.

@Wombat no. It is propagated to the caller

@asgs oh rly 🙄

@asgs Really? Who knew!

???

what language is it?

At least the throw is there

@hubiruchi C#

Could have at least added some more info and thrown a new exception, containing the original as an inner:

throw
{
throw new Exception("some interesting info", e);
}

@JoshBent so why not only throw; to keep the original stack trace

@hubiruchi it's not mine, just something I found

Throw & catch are ridiculous language constructs, and don't belong in any modern language.

If a function returns an error, it should RETURN an error, preferably using monadic types.

People reject this as being "Too FP", but in my opinion monadic return types are neither FP nor OOP, they're just OP.

Throw/catch is the new GOTO or Eval.

I had to write something like that last week. The exception was being directed to stdout, ugh.

Do not ever "throw e;" like that, you will lose the stack trace, either use:

throw;

or:

ExceptionDispatchInfo.Capture(e).Throw();

@bittersweet "Return an error"?

How do you "return an error?"

Adding the error into the return type of every method?

Using dynamic typing and check the return value of every single method you call, to see whenever it is a string/object or error?

How do you trace where the error comes from?

P/s:

Exception does not mean "goto", it means "GO BACK" on errors,

so you can write code going forward, and deal with errors separately later.

@nam17887 That "deal with errors separately later" is the problem, because dealing with the shit becomes optional, and is commonly skipped.

Opening a file could throw an exception in many languages, because a file might not exist.

But take Rust as an example: the return type would be Result<File, Error>. It's a little Schrodinger box, containing either a file, or an error. The calling function can choose to handle any errors and grab the file, or just pass on the result together with any errors that might be in there. But the only way to "unwrap" that file out of the package, is to deal with any errors.

A Result<T, Error> is more honest: Why lie to the caller that you return T, if it's not the only return value that the function has?

Rust goes kind of all-in on this with not only pattern matching for unwrapping, but also special unwrapper functions, expect methods, and the ? operator — but at the end of the day the result is that error handling is very explicit.

That means that errors only propagate to the user if you very explicitly tell it to do so, instead of "because you forgot to catch it".

It also means that when using libraries, you rarely have to check the documentation for possible errors: The type signatures will tell you what's up.

e is hot potato!

@bittersweet sounds like you'd be a fan of go, huh?

func foo( a, b int ) ( n int, e error ) {
//asdf
return ( 5, nil )
}

@GodlikeBlock Go has a lot of awesomeness, but it's missing a few crucial type system features.

@DefiniteGoose

1. Throw
2. Catch
3. Throw
4. Catch
5. Throw
6. Catch
7. Charge for the juggling act
8. Profit.

@Wombat yeah, one bat in each arm 😂

This is your friendly reminder that throw/catch is useful for logging known errors when they occur, and capturing the output/stack trace of fatal errors when they occur. I've seen way too many devs rely on /var/mail to catch their fatal error outputs only to have no info when asked.

The catch block was just curious, jeez.

Fuck it, just throw eeeeeee’s!

Cause you can't write //WTF in there..