hi, suppose you have a 3rd party class, like

XXSubject

from RxJava that you init with default value .. but then you want to access this

value

elsewhere in code, but its marked as

Nullable

so you have to treat it like so in Kotlin as well, so if I want to access it, i should check for null value, but in this case, I know that its not null, because I’ve put default value there. Whats the best practice here? Lately we (at our company) are trying to get rid of all unnecessary

!!

and we treat them like code smell, but here its completely legit, but still feel kind of wrong. I can make extension on Subject as in android framework something like

requiredValue

that will perform !! for me and I will not see it in my code, but is it worth it? thanks!

Opinions ahead: I find that

!!

has a purpose, occasionally. There are just some cases where some value return is allowed to be nullable, but in your specific use-case, it never will be. In those cases, I find that forcibly unwrapping the nullable type is acceptable. If your application crashes on that line, that indicates a deeper data-validation issue on your end. As an example, when using coroutines with retrofit2 (Android), acquiring the parsed body can very technically result in a null, but in the case of a successful result, if the API I work with is returning JSON that I’m expecting and I’m setting up the correct expectations for parsing it, there’s absolutely no reason that the parsed body would ever be null. If it ever is, there’s a more critical issue to investigate. If you attempt to gloss over issues like these with

?.

and no recovery path, you can sometimes end up putting your application in a “dead” state where it’s technically running, but nothing can actually happen. I strongly believe that it is better to crash and find this issue, or have some kind of alternate recovery path, rather than have the end user end up floundering in a mostly-non-functioning app-husk.

I had this opinion too, but our company’s policy in a new year is to minimize crashes and check this weird cases and log them if they happen.

!!

does not automatically indicate a potential crash state. We use

!!

to indicate talking points in code review. More eyes on a problem will reduce the chances that any uses will actually cause a crash. A small caveat that I didn’t mention, when you force-unwrap, you should store the result in a locally scoped container to prevent having to

!!

all over the place.