5 ms·

> 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

• madeofpalk 10y ago
  Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
  • sly010 10y ago
    Sure, we can always make up an examples. 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.
    • geofft 10y ago
      For client-side webapps? Users are just going to hit reload and move on. For just about every website I can imagine, if your two options are to leave an extremely rare bug that's impossible to reproduce, or to effectively take the website down for all users, the former is the unambiguous right choice.
      • sly010 10y ago
        Well, if the bug is so hard to reproduce it would not take the website down.
    • extrapickles 10y ago
      I have found it better to have UI code to use undefined over exceptions, and back-end code to use exceptions over undefined as the client should have properly formatted the request. 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.
  • squeaky-clean 10y ago
    Seriously. A really common example, ever have a website that completely fails to load when you're running adblock? Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?
    • jnbiche 10y ago
      The answer is: that's an expected failure, so you make the error handling explicit by catching the error and taking care of it appropriately (including proceeding to the rest of the page load, naturally). Implicitly handling errors behind JavaScript's loose typing rules is a recipe for disaster.
      • barrkel 10y ago
        Explicitly handling errors is almost always a bad idea, no matter what programming language it is. There are very few errors you can reasonably handle, and they must be designed for. It's specific application domains that need different handling strategies: e.g. embedded, device drivers, software that's trying to maintain some very strict invariants. A web page isn't usually one of them. 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.
        • klibertp 10y ago
          Take a look at Common Lisp and Dylan and their respective condition/restart systems. This is how error handling should look like: they let you handle your errors where it makes sense and naturally recover from them if it's possible.
    • sly010 10y ago
  • Waterluvian 10y ago
    Catch the exception and pass. It's why I like python's attitude toward this. It's explicit, not implicit and therefore easier to read and maintain.
• e28eta 10y ago
  Something I find very interesting about Swift is it's complete reversal of opinion from Objective-C on this topic. 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.
  • spankalee 10y ago
    There is room for both, but it should be explicit in my opinion. Dart for instance has null safe operators // not null-safe: foo.bar.baz(); // null-safe: foo?.bar?.baz(); If your type system also does null tracking, then you can see where you might have null values and decide to use the null-safe operators.
    • samcal 10y ago
      Swift has the same syntax for its nullable types. It's also conceptually similar to Haskell's monadic bind over the Maybe type, where your example would look like foo >>= bar >>= baz The nice thing about this approach is that (>>=) is not specific to the Maybe type, and can be extended to other data structures, include one that passes along error messages in the "null" type through the sad path if it encounters them. This would be in the (Either a) monad.
• jdd 10y ago
  Many times folks understand that values can be nullish. Libs like Lodash treat them as empty collections to avoid repetitive nullish check scaffolding.