views:

57

answers:

2

Regarding data validation, I've heard that the options are to "fail fast, fail early" or "complete validation". The first approach fails on the very first validation error, whereas the second one builds up a list of failures and presents it.

I'm wondering about this in the context of both server-side and client-side data validation. Which method is appropriate in what context, and why?

My personal preference for data-validation on the client-side is the second method which informs the user of all failing constraints. I'm not informed enough to have an opinion about the server-side, although I would imagine it depends on the business logic involved.

+1  A: 

For trivial errors such as invalid inputs or missing data, it's up to you how convenient you want to make the system for the user. It could be very annoying, for example, if somebody was importing a full spreadsheet of data into a system and the first row failed and you said "first row failed." The user fixes the first row, imports, and gets the message "second row failed." Imagine there are 65536 rows. You already know you're not going to do anything with the data, but do you want to make the user's life easier? Again, these are the trivial errors I'm discussing, and of course you will be designing a system that validates all data before processing.

For more serious errors that either you do not expect or are more than mere validation issues, revert to fail fast and hard.

Anthony Pegram
+2  A: 

Part of why this is confusing is that people don't discuss orthogonality as part of the criteria. 'Fail-early' is useful so that the error is caught where it happens, not downstream. But for orthogonal failures, there is no downstream, or multiple downstreams.

For example, most user forms are filled with lots of independent questions, like username, password, email, for example. Since they're independent, wait until all 3 arrive, and describe all errors at once. Making the user go through three submit-check-complain cycles is preposterous.

Gregg Lind
Thank you! That explained it really well.
Vivin Paliath
I'm glad you found it helpful!
Gregg Lind