in reply to undef is undef
Even though it may sound very pedantic and old-fashioned, I aggressively write code that verifies that something which might legitimately be undef is or is not. Then, I enclose blocks of code in exception-handling blocks which, if they go off, package the exception message in another, case-specific class of exception object and then throw that. I don’t use “well, an exception has been thrown, so eat the exception and then do this,” because an exception could be thrown for any reason, not just the one I expect.
I would politely argue that you should never write that “merely ‘works’ (sic).” Because there is only one agent out there with a clear chance to determine whether the app is or is not working properly, and that agent is: the application itself.
The next argument is in favor of clarity above all other considerations. Go ahead and write two, three, four statements instead of one “clever” one if the multiple-statements approach is “obvious at a glance” and/or more maintainable in the decades to come. You probably have CPU-power to burn. (Maybe you legitimately don’t in high-science, but in bread and butter business apps you certainly do ... and what you can’t afford is risk. Especially the risk of undetected application failure.)