I've been waffling back and forth over whether or not to build a parameter validation method(s)...
I guess it's a good idea, but I would have to rewrite soooooooo much at this point...
What I sometimes do is to separate parameter validation out from the workings of the method so that I can call the method without having to do parameter validation (I don't try and write a generic "parameter validation" method because what qualifies as a valid parameter varies from method to method).
The other methods in the class can call the private method on the assumption that "yes, I know what I'm doing, the parameters are fine - I've already checked...."
public function doSomething($params)
// validation stuff
private function _doSomething($params)
// really do stuff.
That's a good idea.
I've been trying to teach myself to find the "last minute" point of validation for any given parameter (e.g., I have a method that uses/proxies/whatever another; so it should ignore validation and just let that other method worry about it).
I have encountered a few people who subscribe to the "only one return statement" philosophy, to the point that they tell me "that's the proper way of doing it".
I personally don't follow that, but if the function or method ends up that way, then so be it, but I'd rather not have a ton of nested if statements like NogDog's example.
On the topic of exceptions... I haven't used them that extensively. Is that bad? I usually return false or some string (depending on the situation - but usually false) when there's unexpected behaviour.
High Energy Magic Dept.
For me, exceptions are for the sort of "unexpected behavior" that would result in a "WTF?" response, as opposed to, say, something that shouldn't normally happen but I can easily envision happening in some situations (e.g. bad user input). If my PDO::__construct() fails, that's probably a good candidate for an exception, since in theory it should always work unless the DB server is down, someone has changed the password -- things that are definitely not "normal". But as with much of the other neat stuff we've been discussing, I personally take any such rule as a rule of thumb, freely deviating from it when I feel it makes for a cleaner, easier to maintain code base. For instance, it might make sense in some application to throw a UserInputException if validation fails, if the framework being used would allow you to catch it somewhere up the stack where you could use it to redisplay the form with the data in that exception object being used to display the error to the user. (Not sure I'd ever do that, but I can see a potential use case for it.)
Originally Posted by Bonesnap
Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be." ~ from Nation, by Terry Pratchett
"But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!" ~ http://www.oreillynet.com/ruby/blog/...ck_to_p_1.html
I've had to deal with the "one return() statement only" methodology here... but that's probably because I work mostly in C these days so "throwing an exception" isn't an option.
In short, using them would give you a well defined structure for errors. If the rest of your code is well structured and you create your exceptions to match, they'd provide the similar benefits as good structure would for the rest of your code.
Originally Posted by Bonesnap
I'd say that's a bit imprecise. It's also most definitely an exception - depending on context and perspective. And those are different from within each separate part of an application, which means that the validity of the statement depends entirely on what is referred to by "something".
Originally Posted by NogDog
PDO::construct should not fail, provided it's given reasonable input. Neither should User::construct() fail provided reasonable input. But just like PDO will throw an exception when it can't follow it's "ordinary program flow" or "give us what we asked for" (a new instance), so should User::construct throw.
Originally Posted by NogDog
Username validation is actually a good example. Common constraints: alphanumeric, max string length, unique. On new user registration, if you ask the database to check if there is already a user with $username, you get no error and no PDO exception. But if you try to store the user, you get a 22001 data truncated which leads to a PDO exception.
As far as probabilities goes, I'd say it's reasonable to expect a SQL-writing user to sooner or later execute a SQL query that will fail some constraint.
will return a user if provided user name is ctype_alnum, mb_strlen() < User::USERNAME_MAXLENGTH and no such user exists in the database. But if I fail to check either, I will most certainly expect PDO to throw no matter which of those checks fail. Consistently, from code calling User::isValid($newUserData), I would expect a simple true or false (or using validation of compound data, possibly indicating which entry(s) failed). But I would expect a call to User::create to throw.
You might to argue that User::createFrom will return a new instance, while User::store will fail. First off, I'd still say User::store should throw. Moreover, I'd claim it'd be reasonable for User::validate to either perform all validation right away (preferably -> leads to no invalid user instance ever existing), or leave all validation to store (or even the database, which is called from store), since that _hopefully_ will not lead to coders assuming they can trust User instances to be valid.
Also note that PDO::perpare will not throw for "SET someField = 'too long string'", because it's not an exception from this perspective. To prepare, it's a qestion of valid SQL code. But calling execute will lead to an exception, because from its point of vue there would be a violation of integrity.
It seems reasonable to define "exception" as being "exceptional to expected behaviour", since it leads to consistency in how to use them and how to regard them. Using a circular definition of what constitutes an "exception" as relating to its probability of occuring, instead seems like a rather good idea to throw one.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)