Writed this code but looks just like java with dif...

# getting-started

[Vinicius Araujo]

Writed this code but looks just like java with different sintax, what would be a kotliner way to write such function?

fun StringValues.getUuidParam(name: String): UUID {
    val id = getAll(name)?.firstOrNull() 
    if(id != null)
        try {
            return UUID.fromString(id)
        } catch (e: InvalidArgumentException) {
            httpException(developerMessage = "Parameter $name does not contain a valid UUID")
        }
    else
        httpException(developerMessage = "Required param $name is not present")
}

[Alex Crafford]

getAll(name)?.firstOrNull()?.let { 
    try {
         return UUID.fromString(it)
    } catch (e catch (e: InvalidArgumentException) {
            httpException(developerMessage = "Parameter $name does not contain a valid UUID")
} ?: httpException(developerMessage = "Required param $name is not present")

[Alex Crafford]

Using let allows you to 'kotlin-ize' the null check and get rid of that val.

[Alowaniak]

personally I would find
val id = ...orNull() ?: throw httpExc...name not present
Easier to read

[Shawn]

folks overuse let {} ?: without realizing their callsite just looks like if/else but weirder to read

[Casey Brooks]

I agree with @Shawn, I tend to find it cognitively difficult to understand what’s happening with most .let blocks. Sometimes they can be nice, but if you’re doing it to avoid an in/else, it’s easier to understand if you just go ahead and use the if/else. let can also cause subtle but hard-to-detect bugs due to them returning the lambda result and not the receiver (such as this one https://github.com/robfletcher/strikt/pull/178/files), so you have to be careful when using them

[Alex Crafford]

I mainly use them to check null cases. For returns on the lambda don't you have to annotate it? like for example

return@lambda

[Alowaniak]

Yea imo you might want to use them if you don't have the else branch and need to do some stuff with it, but otherwise there's probably a clearer construct you can use

[Alowaniak]

@Alex Crafford the last expression in a lambda is the return value for that lambda

If you want to return early you'll need to use label
-at least, iirc-

[Alex Crafford]

Right so in comparison

return thing // returns at the method level
 return@thing // returns at the lambda level

[Alowaniak]

Yes and "a"?.let { null } == null

Oh sorry just noticed that in op's case it wouldn't be a problem

[Vinicius Araujo]

Thanks everyone, based on comments I ended up like this

fun StringValues.getUuidParam(name: String): UUID =
    try {
        val id = getAll(name)?.firstOrNull() ?: httpException("not present")
        UUID.fromString(id)
    } catch (e: IllegalArgumentException) {
        httpException(developerMessage = "not valid")
    }

[Alex Crafford]

I like it