> if you don't mind throwing an exception when given invalid input such as null or undefined
That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.
That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.
Obj-C basically has the behavior GP wants: call a method on nil (aka: null) and it returns nil/false/0. It's possible to write concise & correct code that relies on this behavior.
Swift turns it into a fatal runtime error, and uses the type system to help prevent it from happening.
I think there's room for both (probably not in the same project though!). A lot of successful projects have been written in Obj-C, and some of them rely on the behavior of nil.
However, it's harder to maintain the code. You have to reason about whether nil is possible and does the code do the right thing, or did the original author forget to consider the possibility? It's really nice when the static type system forces the programmer to be explicit.
Having used both paradigms, I honestly don't know which I'd prefer for JS - especially considering it's lack of static typing. It might depend on whether I was writing application or library code.
// not null-safe:
foo.bar.baz();
// null-safe:
foo?.bar?.baz();
foo >>= bar >>= baz
There are perfectly valid reasons why silently failing is OK.
Perhaps if you are using null to represent something explicitly in your data. But silently failing on undefined is just going to lead to an other bug somewhere else entirely and half a day of debugging.
I would much rather fail early and loudly than having to hunt down some anecdotal bug that happens every prime-th national holiday and is impossible to reproduce.
Having functions/methods return undefined is a huge time and complexity saver for UI code as the application could still be in the process of getting input from the user that then would be passed off to the back-end code once the user was done changing their minds. No point in having a dropdown throw an error because the user is still deciding what they want to appear in the dropdown.
Usually errors should be sent up the stack to the request / event loop and logged / telemetry / etc.
The question here is something different, though. It's what should be considered an error, vs what should use the null object pattern. I don't think anyone can make a categorical judgement on which is better without context. It's suggested here that the null object pattern implemented by lodash is desired; I don't think it's wrong in principle to rely on it, as part of a cohesive design - e.g. it's used in such a way that it doesn't make development or finding bugs harder than necessary.
That sort of thing should not be handled by a low level utility library, because at best it will only do the right thing 50% of the time. It should be handled explicitly on a single interface between your software and the tracking module.
I would probably wrap it and explicitly ignore things in the wrapping code if the tracking module is missing.
And yes, I would rather see an empty page so I know to temporarily disable the adblocker, than have a page (e.g. seamless) that silently fails to order your food at the very last step.
You will argue that it's better for the users. No it's not. If the site is broken, it's easy for them to understand. They can at least go somewhere else to order food. If everything looks like it's working but it isn't is very-very frustrating.
I can also catch and log errors and fix them, but hidden bugs will just stay longer and frustrate users, because they will think they did something wrong.
It depends if you're running ads on the page... /s
It's why I like python's attitude toward this. It's explicit, not implicit and therefore easier to read and maintain.