```try { ... } catch { e -> ... }``` `...

# language-proposals

[Hullaballoonatic]

try {
    ...
} catch { e ->
    ...
}

try foo() catch { bar(it) }

try foo() catch bar()

or as @Marc Knaup suggested:

try foo() else bar()

instead of catch in the event you are ignoring the throwable

[Marc Knaup]

Side note: 2 & 3 would change `e`/`it` from Exception to Throwable I guess.

[Hullaballoonatic]

right, sorry. didn't know what the default type was. But also, why wouldn't `e`/`it` be the precise class of the throwable thrown?

[Hullaballoonatic]

i'll fix that

[Hullaballoonatic]

thoughts otherwise?

[Marc Knaup]

#2 implies that you can pass a lambda to catch. That could imply that you can put any expression to catch.

Why the {} around the 3rd example?

[Marc Knaup]

How would it know what will be thrown at compile-time?

https://kotlinlang.slack.com/archives/C0B9K7EP2/p1560548930074600?thread_ts=1560548474.074200&cid=C0B9K7EP2

[Marc Knaup]

`e`/`it` must have some type at compile-time.

[Hullaballoonatic]

ah

[Marc Knaup]

val foo = try something() catch null

😄

[Marc Knaup]

It's quite analogous to if & else

val foo = if (something()) a else b

It just has an additional condition.

[Marc Knaup]

It reads weird though. catch null

[Hullaballoonatic]

the block enclosing the last example just shows how you could enclose multiple lines and also make use of the exception via the lambda format

[Hullaballoonatic]

it's kinda like a reverse of if else expression

[Marc Knaup]

The short form is probably more like

val foo = try something() else null

or using lambda

val foo = try something() else { it.message }

[Hullaballoonatic]

i agree

[Hullaballoonatic]

it'd be like an else block but it also passes the exception as an argument to the lambda function that follows

[Hullaballoonatic]

if you choose to write a lambda

[Marc Knaup]

Downside of the short form is that you cannot declare what to catch. You'd always catch Throwable which isn't good 🤔

[Hullaballoonatic]

so then you could also write this?

try foo() catch(e: Exception) bar()

[Hullaballoonatic]

essentially a reverse in the formatting of

if (someBool) foo() else bar()

[Marc Knaup]

yeah

[Marc Knaup]

maybe else could imply Exception for cases where you don't care about the kind of exception - but catching Throwable is overkill (as it is usually)

[Hullaballoonatic]

i like the idea

[Marc Knaup]

catch always with type, else without and implies Exception

[Marc Knaup]

In the cases where I'd want a super concise style I wouldn't care about the type of exception anyway.

Like val currency = try Currency.getInstance(code) else null

[Marc Knaup]

Today I use

val currency = runCatching { Currency.getInstance(code) }.getOrNull()

which feels weird

[Marc Knaup]

And may catch Error 🤔

[Hullaballoonatic]

yeah, that is definitely not an optimal solution for readability, but understand why you do it.

[orangy]

Oh, the famous VB on error resume next

[Hullaballoonatic]

😅

[r4zzz4k]

Wow, I was having a deja vu feeling about that RxJava's onErrorResumeNext operator, but never managed to understand why. Now I see that was from my childhood ramblings with VB 😁

[r4zzz4k]

Taking another thought, that's even more logical as RX originated as a C# library thus having a connection with VB via .Net.

Sorry for off-topic, just found it a bit funny :)

[Dico]

I like the idea of try else
But it might lead to exceptions being overused

[littlelightcz]

hmh, I am quite fine with runCatching for now 🙂