> if you are trying to report to the user "that code already exists, they must be unique" or "name missing, it must be provided" then you have failed input validation as that sort of thing should be picked up on much earlier in a request lifecycle IMO.
1. Not necessarily, most applications could use a well-designed schema to let the database do these validations and send improved results back to the user, it avoids duplicating (or triplicating) validation information. Especially for things like UNIQUE constraints, you're going to hit the database in-application when the DB will do it anyway? Unless it skips a significant amount of application work it's a complete waste of developer time (and likely application time as well).
2. A good schema can do significantly more complex, interesting and expensive (especially in-application if they need database data) validations than a mere NOT NULL check.
3. In-transaction issues can't be caught by the application server, they'll only blow up in the database.
> I'm surprised how often I still see a full exception report echoed all the way from the data layer of an application up to my browser.
Thus confirming that you're completely missing the point. Again, if one wanted to send database error messages to the end user one could already easily do so.
1. Not necessarily, most applications could use a well-designed schema to let the database do these validations and send improved results back to the user, it avoids duplicating (or triplicating) validation information. Especially for things like UNIQUE constraints, you're going to hit the database in-application when the DB will do it anyway? Unless it skips a significant amount of application work it's a complete waste of developer time (and likely application time as well).
2. A good schema can do significantly more complex, interesting and expensive (especially in-application if they need database data) validations than a mere NOT NULL check.
3. In-transaction issues can't be caught by the application server, they'll only blow up in the database.
> I'm surprised how often I still see a full exception report echoed all the way from the data layer of an application up to my browser.
Thus confirming that you're completely missing the point. Again, if one wanted to send database error messages to the end user one could already easily do so.