What (data model) validation function should return?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
View Poll Results: Return boolean value or error message
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)?
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).
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.
Last edited by portonvictor; 12-05-2015 at 08:52 AM.
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
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.
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.
Last edited by sundialsvcs; 12-05-2015 at 11:22 AM.
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.
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
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
Actually, you can return structures... I would use something like:
Code:
struct Status {
unsigned short severity;
int id;
char *message;
}
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.
Actually, you can return structures... I would use something like:
Code:
struct Status {
unsigned short severity;
int id;
char *message;
}
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.