I sent an email to my students today telling them ...

# random

[Ellen Spertus]

I sent an email to my students today telling them not to include !! on assignments, or they would lose points (and their code would potentially throw NPEs).

A few hours later, a fellow professor (not of my course) posted to an internal Team:

Are other people getting anxious questions about details in assignments? "Professor, I put two exclamation points after 'Hello world!', will you take off points for that?"

I let him know that, indeed, I would take points off for having two exclamation points in an assignment.

[rtsketo]

If it can be ensured that NPE won't be thrown why would they lose points?

[Cicero]

Wouldn't it be clear to write that you would take off points for them using Force Unwrapping (Also known as yours "!!")?

And I agree with my fellow coder here, I've been in situations where that was necessary, @John O'Reilly gave a good example in one of his tweets of an unavoidable situation where our !! was necessary:

https://twitter.com/joreilly/status/1571475922338955264?t=YycsZqADlGCs71ZNLSAUEg&s=19

[Ignat Beresnev]

Imo, teaching students to avoid !! is great 👍

If you really need to assert nullability, using ?: throw SomeException("clear explanation") or something similar instead would be so much more productive whenever it gets thrown

[Ellen Spertus]

@rtsketo because there are better solutions, which do not require !!, that I have taught them.

I even created a cheesy video showing me checking that a box was not empty and then my husband (representing another thread) dumping it out while I wasn't looking and then my trying to reach into it again and getting a null value, causing mayhem.

The point of the assignment isn't to make the tests pass but to demonstrate the ability to write null safe code (as well as other skills).

[Davide Giuseppe Farella]

Imho, it is never safe to call !!
Maybe your code will change to actually make that field nullable, so having a require/checkNotNull with an appropriate message will surely throw an exception anyways, but at least it would be easier to spot.

[andylamax]

Truth be told, Kotlin's double bang can be avoided with better models. Even the tweet that has been posted above, has a more idiomatic solution at its very bottom

[Rob Elliot]

I use jOOQ to insert a row into a table that generates its own ID via a sequence, using returning to get the generated ID back. It's a call that I know can never return null - if the insert succeeds I'll get the row back, if it fails an exception will be thrown. As it happens the jOOQ fetchOne method that returns the row is annotated @Nullable.

My current feeling is that adding the noise of a ?: throw Impossible("explanation") is worse than a simple !! in that case.

[Rob Elliot]

I suppose an extension function might make it better:

fun <R: Record> InsertResultStep<R>.fetchExactlyOne(): R =
    fetchOne() ?: throw NoSuchElementException("fetchOne returned null - no rows matched query")

Then it's only messy once and there's a clear explanation if somehow it did happen.

[Davide Giuseppe Farella]

IMHO, asserting a row from the database is not nullable it’s already a mistake 😄

[Rob Elliot]

Then you haven't understood the scenario I was explaining.

[Davide Giuseppe Farella]

Right! I’ve read it again! I’m sorry, you’re right