Good practice of dealing with null reference exception?

[icy inlet]

I currently have this block of code which allows the player to click, hold and move around a gameobject tagged as "broom".

The whole scene will return a null ref error & making it unplayable, if i don't include
the if (targetobject == null) since it returns an object with no collision box

Is using return in some cases a good way of bypassing and dealing with null ref exception?

Good practice of dealing with null reference exception?

[spice moat]

i mean yeah, that's how it's usually done
however, for objects that derive from UnityEngine.Object (like MonoBehaviour, ScriptableObject, etc) you usually wanna use if (!object) return; because comparing them to null can be weird sometimes

[icy inlet]

oh gotcha thanks
could you elaborate on what you mean by weird?

[spice moat]

iirc, due to unity's weird handling of objects, when you destroy a unity object, it doesn't get destroyed fully right away, not sure on the exact details here, which can cause unexpected MissingReferenceExceptions

[grim loom]

if you check for null, that'll be handled

[spice moat]

is it?

[grim loom]

comparing them to null effectively checks if they exist - either the reference is null, or the object has been destroyed

[icy inlet]

ohh i remember encountering this issue from my previous project
iirc it's because something that relies on that specific gameobject can no longer function properly

since it no longer exist?

correct me if i'm wrong

[spice moat]

i see, interesting

maybe I'm misremembering and that was taking about null coalescing operators?

[grim loom]

could be, those use is null rather than == null. unity overloads ==, and is can't be overloaded (it's its own syntax rather than an operator)

[spice moat]

(i guess now that i think about it, that's what "implicit unity object lifetime check" or whatever it is hint means)

[grim loom]

in some cases
this is pulling a lot of weight

it really depends on why the NRE could happen, and what context it's in.

in this case, a physics check, it's perfectly normal that you wouldn't get a hit, so the specific == null check makes sense
but, it's in Update, so returning here could bypass other unrelated actions below. in such a case, you would use a normal conditional rather than a guard clause*.

for another example, you might be doing GetComponent on, say, the same object, or a specific object you should know about. a null there would mean the component doesn't exist, which might be a mistake.
in such a case, you would absolutely not want a silent early exit. you could check for == null and make a Debug.LogWarning or similar, or more commonly you'd just assume it isn't null - then if it is null, you get an error with pretty adequate detail. this is called fail-fast behavior

* a guard clause is basically an inverted conditional with a return/continue/break, basically in this pattern:

// from
if (x) {
  /* logic */
}
// to
if (!x) return;
/* logic */
```it's useful when you have a lot of cases to check, but you have to be aware of the scope of the guard clause.
you've essentially made a guard clause here, but it affects the entire `Update` method, which would probably not be desirable if you want to do anything else after that `if` block

[woeful apex]

Not exactly considered bypassing. Methods that return a reference can be null (if they failed) so you'll always want to be checking if the return is valid.

Really you should always assume the return can be null if it is a reference return.

[icy inlet]

oooo