Skip to main content
edited body
Source Link
Telastyn
  • 109.9k
  • 29
  • 244
  • 373

So what are the pros / cons of a null check versus using the Null Object Pattern?

Pros

  • A null check is better since it solves more cases. Not all objects have a sane default or no-op behavior.
  • A null check is more solid. Even objects with sane defaults are used in places where the sane default isn't valid. Code should fail close to the root cause if it's going to fail. Code should fail obviously if it is going to fail.

Cons

  • Sane defaults usually result in cleaner code.
  • Sane defaults usually result in less catastrophic errors if they manage to get into the wild.

This last point"pro" is the main differentiator (in my experience) as to when each should be applied. "Should the failure be noisy?". In some cases, you want a failure to be hard and immediate; if some scenario that should never happen somehow does. If a vital resource wasn't found... etc. In some cases, you're okay with a sane default since it's not really an error: getting a value from a dictionary, but the key is missing for example.

Like any other design decision, there are upsides and downsides depending on your needs.

So what are the pros / cons of a null check versus using the Null Object Pattern?

Pros

  • A null check is better since it solves more cases. Not all objects have a sane default or no-op behavior.
  • A null check is more solid. Even objects with sane defaults are used in places where the sane default isn't valid. Code should fail close to the root cause if it's going to fail. Code should fail obviously if it is going to fail.

Cons

  • Sane defaults usually result in cleaner code.
  • Sane defaults usually result in less catastrophic errors if they manage to get into the wild.

This last point is the main differentiator (in my experience) as to when each should be applied. "Should the failure be noisy?". In some cases, you want a failure to be hard and immediate; if some scenario that should never happen somehow does. If a vital resource wasn't found... etc. In some cases, you're okay with a sane default since it's not really an error: getting a value from a dictionary, but the key is missing for example.

Like any other design decision, there are upsides and downsides depending on your needs.

So what are the pros / cons of a null check versus using the Null Object Pattern?

Pros

  • A null check is better since it solves more cases. Not all objects have a sane default or no-op behavior.
  • A null check is more solid. Even objects with sane defaults are used in places where the sane default isn't valid. Code should fail close to the root cause if it's going to fail. Code should fail obviously if it is going to fail.

Cons

  • Sane defaults usually result in cleaner code.
  • Sane defaults usually result in less catastrophic errors if they manage to get into the wild.

This last "pro" is the main differentiator (in my experience) as to when each should be applied. "Should the failure be noisy?". In some cases, you want a failure to be hard and immediate; if some scenario that should never happen somehow does. If a vital resource wasn't found... etc. In some cases, you're okay with a sane default since it's not really an error: getting a value from a dictionary, but the key is missing for example.

Like any other design decision, there are upsides and downsides depending on your needs.

Source Link
Telastyn
  • 109.9k
  • 29
  • 244
  • 373

So what are the pros / cons of a null check versus using the Null Object Pattern?

Pros

  • A null check is better since it solves more cases. Not all objects have a sane default or no-op behavior.
  • A null check is more solid. Even objects with sane defaults are used in places where the sane default isn't valid. Code should fail close to the root cause if it's going to fail. Code should fail obviously if it is going to fail.

Cons

  • Sane defaults usually result in cleaner code.
  • Sane defaults usually result in less catastrophic errors if they manage to get into the wild.

This last point is the main differentiator (in my experience) as to when each should be applied. "Should the failure be noisy?". In some cases, you want a failure to be hard and immediate; if some scenario that should never happen somehow does. If a vital resource wasn't found... etc. In some cases, you're okay with a sane default since it's not really an error: getting a value from a dictionary, but the key is missing for example.

Like any other design decision, there are upsides and downsides depending on your needs.