This can work if the controller uses a try catch and handles the exception properly passing the error up the chain to an error output from the rest controller.

Personally I hold the errors in an array which is useful when validating a form when you want to show multiple errors from a save attempt.

However I do throw an exception if the model is somehow incorrectly configured. Like a validator method being expected but not defined.

I see this a lot with Java style validations. Everything is an exception or can be one. Try catch hell everywhere and there are two schools of thought. Let the exceptions bubble up. Or catch the exceptions you expect at the abstraction, letting the rest bubble up.

Exceptions are imperative, but validation should be declarative (only requires pure functions to work out validation state given stateful input parameters).

Exceptions are a really bad match for marking validation (even ignoring the arsefest that is debugging exceptions during keyboard input events - ugggh).

The DOM has onInvalid events[1] that are fired on form submit (not blur), and there is an :invalid[2] pseudo class for highlighting input errors. Not a perfect API, but certainly relevantly interesting.

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl...

[2] https://developer.mozilla.org/en-US/docs/Web/CSS/:invalid

Well that's weird since java validation frameworks usually collect validation failures before throwing.