Seems to me it would be good idiomatically if `cat...

# language-proposals

[nwh]

Seems to me it would be good idiomatically if catch could receive errors as a parameter, like this:

try { ... } catch { it.printStackTrace() }

I assume this would be a breaking change, but just allowing it to receive a parameter wouldn't be (no implied it):

try { ... } catch { err -> ... }

If both of these are breaking changes, maybe the syntax could be changed to handle instead of catch, and the try statement would have to have one or the other. The current syntax of catch drives me nuts.

[Ruckus]

How would you catch a specific type of exception, especially when you have multiple catch blocks?

[deviant]

try { ... } catch { npe:NullPointerException?, so:StackOverflowException? -> ... }

[gildor]

Current syntax is pretty common for many languages.

[gildor]

Your proposal is also bad because catches all possible errors, such as runtime, VM or OOM errors and it’s very often not what you expect

[gildor]

I think easier would be just write simple wrapper that works as you want with almost the same syntax

[gildor]

Try { }.catch { err -> doSomething(err) }

[gabrielfv]

And what would be the best way to specify the error being caught? Try<NullPointerException> { ..., ... catch(NullPointerException::class) { err -> ...?

[gildor]

Yes, you can use approach, but I’m talking about just do not specify and catch everything (or only Exceptions, no Errors for example). It’s what original proposal does
Main problem with specifying exceptions is that you often want to specify multiple. Instead of completely change syntax I wold better to work on multiple exception catch proposal for Kotlin

[Andreas Sinz]

What benefits would this have over the current way it is done?