Seems to me it would be good idiomatically if `cat...
# language-proposals
Seems to me it would be good idiomatically if
could receive errors as a parameter, like this:
Copy code
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
Copy code
try { ... } catch { err -> ... }
If both of these are breaking changes, maybe the syntax could be changed to
instead of
, and the try statement would have to have one or the other. The current syntax of
drives me nuts.
🤔 1
How would you catch a specific type of exception, especially when you have multiple catch blocks?
Copy code
try { ... } catch { npe:NullPointerException?, so:StackOverflowException? -> ... }
Current syntax is pretty common for many languages.
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
I think easier would be just write simple wrapper that works as you want with almost the same syntax
Try { }.catch { err -> doSomething(err) }
And what would be the best way to specify the error being caught?
Try<NullPointerException> { ...
... catch(NullPointerException::class) { err -> ...
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
What benefits would this have over the current way it is done?