Functions should throw exception on invalid args

In general I believe that it’s better when functions called with invalid argument throw early, because such approach leaves less space for bugs.

Question is how far should we go implementing this, considering that we have no builtin facilities like languages like TypeScript have.

For example see #7125.

• I’m sure that more strict conditions (introduced there) are good. There is no explicit type checking, but code is composed with type-checking in mind, and intentionally fails on many cases of invalid args.
• But should we put that to the test (like done there)? I have some doubts, because that “fails” are not in specs, so they are specific to current implementation. Anyway, it should not be a problem to fix (or even remove) tests when we will need that.
• Still things are not consistent now: not all cases of invalid args are covered. E.g. DomEvent.off doesn’t fail if pass invalid object instead of el. And (in other functions) event argument is not validated at all. All such cases could be covered with explicit type checking, but I suppose that would be overkill.

Thoughts?

[johnd0e]

If you want to implement this yourself then better discuss all details in new PR.

This issue is created to discuss general questions, e.g. how far should we go in arguments validation. Should we cover as more functions/methods/constructors as we can? What of them are error prone (more often misused)? How should we avoid (potential) performance loss?

1. One possible approach is adding validation to factories (e.g. toPoint()) but not to constructors (new Point()), thus leaving space for custom optimization. E.g. when you need to process huge dataset - you may prefer Point.
2. But it’s not clear to me if such optimization is ever needed. To understand this we should compare real performance wit/without arguments validation. And it may appear that difference is miserable.

[Falke-Design]

There is also a problem with Tiles. If the maxNativeZoom is set with a string value, the tile-request contains sometimes a high zoom value: https://github.com/Leaflet/Leaflet/blob/d6d6051ac6acbc2c68b6b0f8ef1707cf91054f16/src/layer/tile/TileLayer.js#L209-L220

this._tileZoom / zoom is then for example "17" and zoomOffset which is 0 is added to it, which returns 170. If a tile is requested with zoom 170, the browser window breaks / stops running. But I didn’t found out why this happens