There is normal to have an unexpected exception in a life.

If you learn to code, you know thats why there is try/catch exist, so when you try something and there is an exception you know how to pass it.

Why? So whenever something goes unexpected from your expectation you already have an exception for it and just pass it rather than making your entire mind crashing!

Do languages really have that?

I have the else directly under the "critical" code to execute in try block without else

But how is "else" different from "try"?

Also exceptions can be thrown in every block... Maybe going functional and using "Either" is the way to go?

Else is a part of 'try'. Just put it after the code that might fail.

That's one inefficient way to replace a newline. It's like chaining Promises with then() but without Promises.

If you ask me, the best way to handle those things is how Rust does it - just put a `?` after the possibly failing operation and carry on.

@deadlyRants but it's not the same as a try block

Try catch in general is utter bullshit. Look at C or even better Golang how it's done.

@nitwhiz ++ an error is just another outcome

@nitwhiz true

@iiii The ? operator is literally syntactic sugar for Rust's try-catch counterpart. And can be used within nested expressions, so it often saves quite a bit of boilerplate and indentations.

@deadlyRants but iw works only for chained calls, no?

@iiii Not sure what you mean, but you can use it with any function call that can return an error or an optional result. The only condition is that the caller needs to be able to return the same error type, which is usually handled by defining a project-wide enum type that encompasses all errors and optionally casts errors from 3rd party libraries.

But this also means it cannot be used directly in the main() function as it doesn't return anything.

try:
...
except:
...
else:
... dumb block!!!
finally:
...

No need for an else as you can catch exceptions of various types in most languages... And also the keyword 'else' is conditional and doesn't fit in that position.

@deadlyRants I mean that it does not affect the next expression. Or is it not like that?

@iiii In case of an error it basically causes the function to immediately return with the error value, everything after that is not executed. It's a shortcut to pass errors back through the call hierarchy.

@deadlyRants so it basically makes the whole function a try block? Sounds like a bit of overcomplication to me.

Just return null for everything except success.

If given shit by anybody, say that's now the DEVELOPERS of LANGUAGES do it whilst pointing at PHP.

@HiFiWiFiSciFi what if 'null' is a valid return value even if there's no error?

@iiii Then nothing was broken in the first place :)

@HiFiWiFiSciFi no, there may be the case when there may be an error but also 'null' being a valid value.

@iiii

try {

if(x==null) {
exit;

// It works!
}
catch {
exit;
}

It's just failing silently all the way down.

@HiFiWiFiSciFi oh,BTW, have you heard of railway programming?
https://vimeo.com/113707214

@iiii Yeah! It is kind of that.

Like more often than not I need to do some CRUD operation against some DB or API or other Datasource.

So I'll just have a "working" path, I guess this is called the "railway" and then everything else will fail silently or return null.

Then all that needs be done on the front-end is have a default value (or pass a default from the backend).

So either "were doing a CRUD operation that works" or we have a null so we need to do a CREATE instead of an UPDATE. Then you code the path for that based on the null... and you're STILL ON THE RAIL.

CHOO CHOO mutherfuckas

@SuspiciousBug if there's an exception in the else block, it's not caught by the block above