The accepted test for determining if the user passed in a value for an argument, say arg1, has been:

if (n_elements(arg1) eq 0) then ...

But this can be thwarted since IDL 8.0, which introduced operating overloading, by an object that overloads ::_overloadSize and returns 0.

Brian Griglak in the current IDL Data Point article concludes:

So putting it all together, the best way to validate undefined vs null vs non-null is:

if (Size(val, /TYPE) eq 0) then begin
...
endif else if (ISA(val, /NULL)) then begin
...
endif begin ; I added this line and the next to Brian's code to
... ; distinguish between his three cases
endelse

This is a tricky issue to get right for your particular purposes because N_ELEMENTS being 0 has multiple meanings. In my case, I had two cases that I needed to handle:

1. the number of elements in an array of objects
2. determine if an argument was present (return nonzero value if it was an object with _overloadSize returning 0)

These issues have always been muddled in IDL (ARG_PRESENT doesn’t tell you if an argument is present, it indicates that it was passed as a named variable).

My manner of testing was to use OBJ_VALID if the argument was an object and you didn’t want to use the normal operator overloading returned value:

function mg_n_elements, var, no_operatoroverload=noOperatoroverload
  compile_opt strictarr
  if (~keyword_set(noOperatoroverload) || size(var, /type) ne 11) then begin
    return, n_elements(var)
  endif
  return, n_elements(obj_valid(var))
end

Download src.