Re: Improving ugly(?) design: Data validation
Rune Allnor ha scritto:
At present, the validating method looks like this:
bool validator1::operator()(std::string s)
{
for (size_t i = 0; i<s.size();++i)
{
if (error1(s[i])) {throw exception1a(i);}
if (error2(s[i])) {throw exception1b(i);}
}
return true;
}
The routine checks for a number of errors, and throws
an exception to indicate what type of error is encountered,
and the offending character in the string. If no errors
are encountered, the call returns 'true'.
Why does it return a bool? If the function either returns true or
throws, then you could as well make it return void.
While this works, I am not very happy with it.
First, there is the mixing of return mechanisms.
A good result is indicated by return code while
a bad result is returned by exception.
If you make the function return void, you will get:
* good result: return
* bad result: exception
which is what one would expect.
Second, the different types of errors causes
an elaborate hierarchy of exception types, which
somehow becomes clumsy.
There is the alternative to add error inspection
methods in the class and throw 'simple' exceptions:
class validator2 {
size_t errorpos_;
public:
size_t getErrorPos() const;
bool operator()(std::string);
};
bool validator1::operator()(std::string s)
{
for (size_t i = 0; i<s.size();++i)
{
if (error1(s[i])) {throw exception2a();}
if (error2(s[i])) {throw exception2b();}
}
return true;
}
In this case the type of the thrown exception
identifies the cause of the error and the caller
can use the inspector method getErrorPos()
to identify the offending character.
As far as I can tell, the choise of one method
over the other is a matter of personal preference.
Storing the result of the validation in the validator class is a bad
design IMHO. It requires that the validator object is accessible at the
catch site, which may or may not be happen. Moreover, it makes the
validator non-reentrant.
Or is there some argument (stated above or which
I might have missed) which would be considered
decisive for (not) choosing any of the solutions?
Or are there standard ways to handle these
problems?
I consider return codes and return Variant objects
not to be relevant otions, as much as a matter of
'aestethics' as for any other reason.
Actually, I would steer away from exception in this case. From a
philosophical point of view, a validation failure is not an error
condition and so it shouldn't be modeled as an exception. One possible
approach is to create a polymorphic hierarchy of validation failures
which are instantiated when needed. For example:
struct validation_failure
{
virtual ~validation_failure() {}
virtual void report_to_user() = 0;
};
struct validation_failure_a : validation_failure
{
// state and constructor here
virtual void report_to_user();
};
struct validation_failure_b : validation_failure
{
// state and constructor here
virtual void report_to_user();
};
std::auto_ptr<validation_failure> validator::operator()(std::string s)
{
for (size_t i = 0; i<s.size();++i)
{
if (error1(s[i]))
{
return std::auto_ptr<validation_failure>(
new validation_failure_a(i));
}
if (error2(s[i]))
{
return std::auto_ptr<validation_failure>(
new validation_failure_b(i));
}
}
return std::auto_ptr<validation_failure>();
}
At the call site, the code might be simply:
if (std::auto_ptr<validation_failure> failure = val(str))
{
failure->report_to_user();
}
notice that the auto_ptr will take care of deleting the failure object
if needed. If you don't like auto_ptr, you might use shared_ptr or any
other pointer type.
HTH,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]