What do you usually test for first: true or false? - Page 2
Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23

Thread: What do you usually test for first: true or false?

  1. #16
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    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...

  2. #17
    Pedantic Curmudgeon Weedpacket's Avatar
    Join Date
    Aug 2002
    Location
    General Systems Vehicle "Thrilled To Be Here"
    Posts
    21,865
    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).

    PHP Code:
    public function doSomething($params)
    {
        
    // validation stuff
        
    $this->_doSomething($params);
    }

    private function 
    _doSomething($params)
    {
        
    // really do stuff.

    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...."
    THERE IS AS YET INSUFFICIENT DATA FOR A MEANINGFUL ANSWER
    FAQs! FAQs! FAQs! Most forums have them!
    Search - Debugging 101 - Collected Solutions - General Guidelines - Getting help at all

  3. #18
    Senior Member traq's Avatar
    Join Date
    Jun 2011
    Location
    so.Cal
    Posts
    949
    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).

  4. #19
    Senior Member
    Join Date
    Mar 2009
    Posts
    802
    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.
    Declare variables, not war.

  5. #20
    High Energy Magic Dept. NogDog's Avatar
    Join Date
    Aug 2006
    Location
    Ankh-Morpork
    Posts
    13,915
    Quote Originally Posted by Bonesnap View Post
    ...
    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.
    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.)
    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


    eBookworm.us

  6. #21
    Pna lbh ernq guvf¿
    Join Date
    Jul 2004
    Location
    Kansas City area
    Posts
    19,414
    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.

  7. #22
    Senior Member
    Join Date
    Jul 2007
    Posts
    3,647
    Quote Originally Posted by Bonesnap View Post
    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.
    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.

    Quote Originally Posted by NogDog View Post
    …said purists would say if it's something like validating user input, it's not an exception
    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".

  8. #23
    Senior Member
    Join Date
    Jul 2007
    Posts
    3,647
    Quote Originally Posted by NogDog View Post
    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
    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.

    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.
    PHP Code:
    User::createFrom($data
    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •