From what I remember, the use of the double bang i...

# codingconventions

[dumptruckman]

From what I remember, the use of the double bang is discouraged. However, I find myself using it a lot to intentionally throw an NPE when something really shouldn’t be null. Example would be a SQL query that should either return no rows or a row with a single column with a non null value. There’s no reason the column should ever be null unless someone changed the DDL of the table at which point the NPE essentially just informs them they have more work to do with such a change. Anyone else experiencing this?

[tddmonkey]

In those cases I prefer a ?: error("some useful information about why it failed")

[Shawn]

colin beat me to it

[Shawn]

an NPE doesn’t intrinsically tell you anything more specific than “you’re trying to dereference a null pointer dummy”

[Shawn]

calling error() with a useful message is way more helpful (and easier to search for in the codebase)

[dumptruckman]

Yeah, I guess that’s true.

[tddmonkey]

The only time I’ll use !! is when it absolutely cannot be null but I’m interoping with something that doesn’t let the compiler know

[dumptruckman]

I guess a lot of these use cases are the result of an inline function I created to make getting values from a ResultSet easier. Example: val timestamp: LocalDate = rs["create_date"]!!

[dumptruckman]

though usually the type inference comes from a method/constructor parameter

[dumptruckman]

but I think I just realized that maybe I wrote that function incorrectly…

[Shawn]

mazel tov 🎉

[dumptruckman]

inline operator fun <reified T> ResultSet.get(columnLabel: CharSequence): T? = getObject(columnLabel.toString(), T::class.java)

[dumptruckman]

return type should probably just be T right?

[Shawn]

that makes sense, assuming you’re intending for folks to parameterize the call properly if the field is intentionally nullable

[dumptruckman]

right

[dumptruckman]

Actually, I think there was something peculiar that required that due to the way getObject handles primitives…

[dumptruckman]

Or the interop when inferring types from java primitives.

[dumptruckman]

yeah.. so you could infer from an int and easily use rs["id"] ?: 0

[dumptruckman]

SO… having remembered that, it kind of forces me to use !! to get non-nullable types out of it. I feel like putting ?: error(“…”) after each call to it would quickly get unsightly.

[dumptruckman]

Message(
    rs["create_date"] ?: error("create_date is null"),
    rs["body"] ?: error("body is null"),
    rs["subject"],
    rs["message_id"] ?: error("message_id is null")
)

[dumptruckman]

Would you still prefer an elvis error in this case?

[Shawn]

feel like you could define a different getter if you’re not super attached to the operator fun

[dumptruckman]

Specifically for the cases with numbers?

[Shawn]

well idk about the types in question here but you could maybe have a get() and a getNullable()

[Shawn]

or a getThrowing() if you actually want that to be the exceptional behavior

[Shawn]

your call

[dumptruckman]

The operator part of it was pretty nice I think.

Message(
    rs["create_date"]!!,
    rs["body"]!!,
    rs["subject"],
    rs["message_id"]!!
)

[Shawn]

Message(
  rs["create_date"],  // these will throw
  rs["body"],
  rs.getNullable("subject"),  // this will not
  rs["message_id"]
)

it’s perhaps not as nice-looking but is probably easier to debug

[Shawn]

ultimately it’s up to you what kind of API you wanna publish

[Shawn]

I see where you’re coming from and don’t necessarily disagree

[dumptruckman]

I could abuse the invoke operator for the other case… but that’s probably not a good idea.

[Shawn]

it’s not great, would probably surprise folks (though the scala people might not hate it lol)

[dumptruckman]

Maybe I could just create an extra extension function for the ones that have exceptional cases… I’ll have to fiddle around with that.

[dumptruckman]

rs["id"] { 0 }

[dumptruckman]

overload get with a block param

[dumptruckman]

Less intuitive though I think

[Shawn]

idk, providing a default is pretty different from NPEing if you’ve reached an illegal state

[dumptruckman]

You know… to be fair, if that function didn’t return T? it would still NPE if the result of getObject ended up being null

[dumptruckman]

Which would occur if the programmer made a mistake or if the DDL changed.

[sindrenm]

As an alternative to the ?: error("message") approach, there's also checkNotNull and requireNotNull, which might be of interest. I tend to favor those over !!, at least, and usually also checkNotNull(foo) { "message" } over foo ?: error("message") .

[tddmonkey]

For things like this we have an extension method to make things clearer, so something like:

Message(
    rs["create_date"].orDie(),
    rs["body"].orDie(),
    rs["subject"],
    rs["message_id"].orDie()
)

[Mike]

Although not pretty, I prefer checkNull or requireNull calls. And function returns non-null. More explicit than !!, and throws Illegal exception rather than NPE.

I find that more realistic, as !! should only be used in cases where the compiler can't figure it out, but you KNOW it can't/won't be null at that point.