Introduction

“Is this object nullable?” can mean two different things. Sometimes you want to know whether the current value is null; other times you want to know whether the variable’s type is allowed to hold null at all.

Those are related but different questions. A runtime null check answers the first, while the language’s type system, annotations, or reflection APIs may help with the second.

First Ask Which Question You Mean

In most code, developers are really asking one of these:

• “Is the value currently null?”
• “Can this type legally be null?”
• “How do I write code that avoids null-related bugs?”

The first question is simple and runtime-based. The second depends heavily on the programming language.

Checking Whether the Current Value Is null

At runtime, the direct check is usually straightforward.

1String name = getName();
2
3if (name == null) {
4    System.out.println("Name is null");
5} else {
6    System.out.println(name);
7}

This tells you whether the value is null right now. It does not tell you whether the variable’s type was intended to allow null; it only checks the current state.

In JavaScript or TypeScript, the equivalent might look like this:

1const value: string | null = getValue();
2
3if (value === null) {
4  console.log("Value is null");
5} else {
6  console.log(value.toUpperCase());
7}

Again, that is a value check, not a full type-analysis question.

Checking Whether a Type Can Be Null

Whether a type is nullable is language-specific.

In Java, reference types can generally be null, while primitive types such as int cannot.

String text = null;   // allowed
// int count = null;  // not allowed

In C#, the answer depends on whether you are dealing with value types, nullable value types, or nullable reference types.

1int count = 5;
2int? optionalCount = null;
3
4string name = "Ada";
5string? nickname = null;

Here:

• 'int is a non-nullable value type'
• 'int? is a nullable value type'
• 'string is usually treated as a non-nullable reference type when nullable reference types are enabled'
• 'string? explicitly allows null'

In Kotlin, nullability is built into the type system:

val name: String = "Ada"
val nickname: String? = null

String cannot be null, while String? can.

Reflection and Type Inspection in C#

If you really need to inspect whether a type is nullable in C#, you can handle value types with Nullable.GetUnderlyingType.

1using System;
2
3Console.WriteLine(Nullable.GetUnderlyingType(typeof(int?)) != null);   // True
4Console.WriteLine(Nullable.GetUnderlyingType(typeof(int)) != null);    // False

This works for nullable value types such as int?, DateTime?, and bool?.

Nullable reference types are more subtle. Their annotations are primarily a compile-time feature, not something you can reliably treat as a simple runtime boolean everywhere. In day-to-day application code, you usually rely on the compiler’s warnings rather than runtime inspection.

Prefer Safe Access Patterns Over Repeated Null Checks

Checking for null is necessary, but a better design often reduces how often you need to ask the question at all.

For example, in Kotlin:

val length = nickname?.length ?: 0
println(length)

And in C#:

string? nickname = GetNickname();
int length = nickname?.Length ?? 0;
Console.WriteLine(length);

These patterns handle nullable values safely without long chains of if statements.

Optional and Similar Abstractions

Some languages provide wrapper types to model absence explicitly. Java has Optional, and Swift has Optional built into the language.

1import java.util.Optional;
2
3Optional<String> email = Optional.ofNullable(findEmail());
4
5email.ifPresentOrElse(
6    System.out::println,
7    () -> System.out.println("No email")
8);

This does not mean null disappears everywhere, but it can make APIs clearer by signaling that absence is expected and should be handled intentionally.

Common Pitfalls

The biggest mistake is confusing “the value is currently null” with “the type is nullable.” Those are not the same thing.

Another issue is assuming that all languages treat object nullability the same way. Java, C#, Kotlin, Swift, and TypeScript all make different tradeoffs between runtime checks and compile-time guarantees.

People also overuse reflection when a plain runtime check or compiler warning would solve the real problem more simply. If your goal is to avoid null-reference failures, code structure and type annotations are often more valuable than dynamic inspection.

Finally, be careful with generic “falsy” checks in languages like JavaScript. null, undefined, 0, and empty strings are different values, so use explicit null checks when correctness matters.

Summary

• Decide whether you are checking a runtime value or the nullability of a type.
• A runtime null check usually looks like value == null or value === null.
• Type nullability is language-specific and may be enforced at compile time.
• In C#, Nullable.GetUnderlyingType helps for nullable value types such as int?.
• Safe access operators and optional-like abstractions often reduce the need for repeated manual null checks.