Maybe this sort of thing doesn’t happen too often, but it’s something I’ve started noticing more and more as I read code in the wild.ĭid I miss a case where takeIf() and takeUnless() would be appropriate, or a case when they introduce errors? Let me know, I’m always happy to chat and appreciate feedback. On the other hand, it feels like calling takeIf() or takeUnless() on an expression should at least be a warning in IntelliJ. Kotlin es Null Safety, es decir, que gestiona los nulos de forma segura, de modo que puedes garantizar que tu código no va a producir NullPointerException. The takeIf() and takeUnless() functions aren’t doing anything you can’t do with if/else, it just makes things easier to read in some cases (which I value highly when writing code). These references are interpreted by compiler at. I like the fact if is an expression in Kotlin, and I think that reduces some of the utility of takeIf() and takeUnless(). In Kotlin, the type system differentiates between two types of references. I do find places in my code to use it, but more often than not I use an if/else expression instead. Closing ThoughtsĪs we’ve seen, the places where we might use takeIf() and takeUnless() can be fairly subjective. Basically Kotlin automatically adds null checks at every one. takeIf Īgain, it’s subjective that the takeIf() version is any better, but some might find easier to read. data class Request (val containerType: String, val containerId: String) That automatically happens then because Kotlin under the hood ensures that even if a Java caller passes a null value that an exception will be thrown automatically so you don’t need to worry about that at all.
0 Comments
Leave a Reply. |