What (data model) validation function should return?
 

A question about software design:

When registering a field validation callback for a data model, should it be a pair of a function which returns boolean value and of an error message, or should it be a function which may return the error message (or NULL if no error)?

Returning error message may avoid repeated passing data structures with the same error message more than once.

Returning bool separates logic and usage.

What is better?

I think this is impossible to answer, depends on the actual piece of software (program) that you are writing.

Best regards,
HMW

I am writing an object-relational mapping for our big complicated Web site.

The ORM is to be used for such things as validating Web form inputs.

We are now doing site code refactoring, to rewrite the site with an ORM.

The problem with both methods is that you cannot return warnings...

A boolean is enough for simple true/false tests - but things like a password aren't just true/false (think updating a password - you have a true value when all tests pass, you have a false if required tests fail, but you also have a "maybe" if the required tests pass, but quality checks might not).

I think, we should not complicate the code with "warnings". (Or we may add such code at a later stage.)

I need to decide how to process errors: with a function returning error message or with a function returning bool.

Return an error code, but try to standardize the values, eg:

you throw an exception because that can not be ignored if something goes wrong
or you create an optional type that will be returned and can be queried if valid, if not and you want to access the value, throw.
Now the question is, do you have a programming language that support creating this? or do you stuck with C, than you are limited to return codes

A colleague asked me not to throw exceptions, but just to return a result indicating an error. I am not sure about his reason, but do as he asks.

We use Perl. Perl supports all this.

Exceptions are also preferable because they can occur "many levels deep" in a nest of subroutines, with "the catcher's mitt" waiting at the outer level. When the exception goes off, it "lands directly in the mitt," and all the intervening nest of calls is forgotten. None of the code has to "test return codes and exit." Basically, "if we return from the validation call," the validation was successful. Likewise, if we ever wind up in the catcher's mitt, we know that an exception has occurred.

If your language also supports "finally" clauses, you can arrange for certain things to happen whether-or-not an exception has just gone off.

Particularly useful is when the exception that gets thrown is, itself, an object within a class, which can contain specific information about the exception and which can be recognized by the class (or superclass) it belongs to, within the "catcher's mitt" code.

The second one.

than return a optional type that can be queried if valid and throw if you access the value.
and ask your colleague what he prefers, undefined behaviour or secure code with exceptions, I think the answer should be obvious

Exceptions are good, but ONERRORGOTO was even better in BASIC, or EXLST in Assembly.

Actually, you can return structures... I would use something like:

The severity can be used to for anything from bool (0 = no error, >0 warning level, 65535 = error).
The id can be used for anything (such as an error count, where more than 5 errors becomes fatal),
The message is just a pointer into a static message array for the specific error.

yes of course you can, but you can ignore severity and access message which may point to something or not and have undefined behaviour. And the severity check will not be captured by lint or similar static analysis tools that check that you do not ignore a return value of a function, so this would not pass code review in some environments because it's insecure.