![]() ![]() 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. 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). I like the fact if is an expression in Kotlin, and I think that reduces some of the utility of takeIf() and takeUnless(). 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. If the method being matched is written in Java, then I think that it will work as all Java objects are implicitly nullable. ![]() This is because it can return void and this is not assignable to a non-nullable parameter. NULL is not intuitive in any language, because NULL is an axiom of that language. Therefore, there is no ternary operator ( condition then : else) because ordinary if works fine in this role. takeIf Īgain, it’s subjective that the takeIf() version is any better, but some might find easier to read. If you have a method written in kotlin that does not take a nullable parameter, then we cannot match with it using Mockito.any (). What if every object was an array No more NullPointerExceptions. In Kotlin, if is an expression: it returns a value. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |