@feroz_baig it actually makes sense on some scenarios, such as test setUp/tearDown

the link actually mentions it

@feroz_baig I agree with @menegatti in some scenarios is needed and almost feel natural to do this kind of checking.

Yes i understand. It will make coding simpler.

Alternatively you can make a non lateinit var variable and initially set to null. Then do teardown with variable?.teardown

Agreed

As soon as I step over the line above, the program will crash with a

NumberFormatException

. However, I can evaluate the expression successfully while debugging as you can see from the watches window in the screenshot.

No. Can you catch the exception and print out the stacktrace? It might give you some more clues

sure thing one moment

I get a detail message of

null

and an empty stack trace

Full printout:

java.lang.NumberFormatException: null

As far as I can tell from debugging,

Integer.parseInt()

as well as

toInt()

seem to be sending null to Integer.java. At the call point in Kotlin I have a value, but inside

Integer.java

the value is null

@jackmiras You can hack something ugly together

@User uploaded a file: Untitled

But you’re fighting the language which is generally a bad idea

Hi guys. Any thoughts on processing big xml file in Kotlin?

which one do you prefer in kotlin:

return try {
    true
} catch(..) {
    false
}

vs

try {
    return true
} catch(..) {
    return false
}

i'm trying to use the first one, but it doesn't feel right

return try is a bit more idiomatic

i know, but is it more readable?

I personally prefer the former, but either works

does it get more readable if you use it a lot? 🤔

i think i'll keep forcing myself to do it for now, just wondering if anyone else are having trouble with try/catch in particular

@tipsy for me the first options is better when you wanna do a inline

try{  } catch () {  }

, otherwise I would stick with the second option

I like to pull the

return

as high up in the expression as it can go personally, most of the time. I could see situations where having explicit

return

in each branch would be more readable, especially if the try/catch is very long

@tipsy If your function is defined as an expression you don't need to use

return

at all.

fun doSomething(): Boolean = 
   try { true } catch (..) { false }

thanks, in the cases where i can do that i think it makes more sense

i guess a solution would be to always extract try/catches as expression functions 🤔

When you program with a Functional style and try to keep all your functions pure they can all be expressions and smaller in size composing each other to build larger programs. You'll find that you don't need try catch as often unless you are dealing with APIs that throw exceptions.

Also for proper error handling there are now several libs with

Try<A>

,

Either<E, A>

and

MonadError<F, E>

datatypes that abstract away

try .. catch

blocks, error handling in general and represent Failure and Success as ADTs with folds and other useful combinators.