Vinicius Araujo
09/30/2019, 10:03 PMfun 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
09/30/2019, 10:06 PMgetAll(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")
Alowaniak
09/30/2019, 10:09 PMval id = ...orNull() ?: throw httpExc...name not present
Easier to readShawn
09/30/2019, 10:11 PMlet {} ?:
without realizing their callsite just looks like if/else but weirder to readCasey Brooks
09/30/2019, 10:15 PM.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 themAlex Crafford
09/30/2019, 10:19 PMreturn@lambda
Alowaniak
09/30/2019, 10:21 PMit
, but otherwise there's probably a clearer construct you can useAlex Crafford
09/30/2019, 10:25 PMreturn thing // returns at the method level
return@thing // returns at the lambda level
Alowaniak
09/30/2019, 10:28 PM"a"?.let { null } == null
Oh sorry just noticed that in op's case it wouldn't be a problemVinicius Araujo
09/30/2019, 10:39 PMfun 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
09/30/2019, 10:42 PM