[squeaky-clean]

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]

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]

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]

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]

It's hard for me to imagine why would you want to .map() on a list of 3rd party tracking modules but let's go with your example.

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.

[danmaz74]

> Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?

It depends if you're running ads on the page... /s