Nah, you’re taking me too literally now (and possibly teasing me) but you make a good point that I did not.
Like most (I think) I believe my code is going to follow a “happy-path” once we have got past the BOFH data entry stage.
It’s that which I expect to be broken/abused/hacked, and that is generally where I expect to fail early, though its not a hard and fast rule.
Once past that big fail point, the rest of the logical “happy-path” operations : connecting to database, finding an entry matching an integer (unless the user is actually guessing numbers) and so on I do reasonably expect to work - and failure handling is then handed off to a combination of UnitTests, Exceptions, and error checking in the functions or objects invoked.
Not easy to explain using the example given maybe, but I noticed I am occasionally refactoring blocks in the same fashion, it has to do with proximity of the failure code to the start of the block.
instead of:
if( everything === good ){
// write 30 lines
}else{
ooer_handle_failure();
}
I’m doing this:
if( everything === not_good ){
ooer_handle_failure();
}else{
// write 30 lines
}
The question of proximity is a personal thing, if the above code instead contained:
// write 5 lines
Then I’d just as likely leave it as it was, because I dont need to scroll down and down to find out what the hell happens when the incoming user var test fails.
To take things to the extreme, you could have a 200 line block of code running on success, but if you were debugging (“where the hell did that message come from?” or “what happens of this fails again?”) you’d have to scroll through 200 lines to find out the “or else”.
When I think about it, TBH, its becoming more and more a moot point in my own code as more and more of the complexity is moved into classes and functions.
re: PDO - the best place to learn is of course the manual page, but another place is the site of the guy who first wrote PDO (as a PECL package I think) Dr Evil (Wez Furlong).
The second link on that page might be the slides he prepared and showed at many conferences a few years ago, and I referred to them a lot.
PDO took me quite some time to adjust to, y’know, to have all the syntax at your fingertips all the time, assembling those trusted snippets of code you know just work for the mysql_* functions.
It is class which you have to instantiate, but once you get used to using it and you learn even a few things about OOP, you realise you can simply extend it, or pass a PDO object to any class which need to access your database.
There are lots of benefits to using PDO, security is probably my main one, for the reasons I outlined previously.
I think it was when I started using PDO that I naturally tended to start separating data access from the rest of my code, so you start moving html and css in one direction ( towards templates and views) and data access in another direction ( models and business rules).
So its important for that reason too, although there is a bit of a hill to climb.
