I can see why they did that. Null/undefined checks in templates are messy and ugly, and there are a lot of cases where objects on the scope won't be ready when the scoped element is first rendered.
Templates shouldn't be throwing exceptions for something like customer.name when customer is null. Angular's rendering tries to do something sane by default in a very common case.
If it really bothers you, you can easily write your own click-log-error directive that writes to the console if the function isn't defined.
Actually thanks to Angular's DI system you can replace the base ng-click with one that does throw an error.
I didn't mean the template part in particular, rather think directive arguments, scoping behaviour (the dreaded "wrap your value in an object if you want data-binding").
Sure, not rendering a null value is, while I disagree, a possible choice and certainly useful in certain contexts. However the point about objects not ready should IMO be rather fixed by delaying until the object is ready and I'm actually horsing that if possible so that no uninitialised state is visible at any point.
And again, for production mode you mostly don't want exceptions to pop up, but a strict mode for development is useful. Otherwise someone (who? the customers won't notice this way) has to tell me that some values don't show up (yes, modulo testing).
Replacing those handlers is actually a very interesting idea, I'll try and see how that goes.
Templates shouldn't be throwing exceptions for something like customer.name when customer is null. Angular's rendering tries to do something sane by default in a very common case.
If it really bothers you, you can easily write your own click-log-error directive that writes to the console if the function isn't defined.
Actually thanks to Angular's DI system you can replace the base ng-click with one that does throw an error.