we already have nice `to&lt;Type&gt;OrNull()` string extensions <https://github.com/Kotlin/KEEP/blob...

# stdlib

[brk]

we already have nice to<Type>OrNull() string extensions https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/string-to-number.md
But don't you think it would a good idea to add generalized version of 'try-or-null' to stdlib? like:

val date = tryOrNull { myAwesomeDateTimeParser.parse("2017-13-32") }

which is equal to:

val date = try { myAwesomeDateTimeParser.parse("2017-13-32") } catch(e: Exception) { null }

[voddan]

brk: catching the exception has awful performance and is an anti-pattern

[voddan]

In cases like yours I think it is better to try and find an API which does not throw exceptions

[brk]

yeah, i know, but in some cases it's reasonable. just like `toIntOrNull()`: I bet you don't want to know the exact reason every time you string doesnt fit into an int

[voddan]

toIntOrNull() doesn't catch an exception

[voddan]

we spoiled a lot of blood to get it 😉

[voddan]

The general rule is that you don't put nice easy-to-use methods into stdlib if they have performance problems

[brk]

oh, thanks, got it. just curious: how times does it slower to use try {x.toInt()} catch { null } instead of current implementation of toIntOrNull() which parses string by its own?

[voddan]

A comprehensive reading: https://shipilev.net/blog/2014/exceptional-performance/