On Wed, January 3, 2007 3:43 pm, Roman Neuhauser wrote:
> > function print_any($any){
> [34 lines of a switch ellided]
> > }
> Nice. Now I see how the dynamic nature of PHP boosts development. :)
It was intentionally excessive to prove a point.
And because copy/pasting the possible values from the manual was
easier than thinking. :-)
I know you have a smiley and all, but, really, it's a write-once
function, and it's guaranteed to work for PHP 3 through PHP 5, with
reasonable error-handling for PHP 6 and beyond.
gettype hasn't changed in a long time and is unlikely to change in
future versions.
That __toString magic didn't even exist in earlier versions, and has
already changed out from under you once, right?...
So which one really makes sense to use for robust code? :-)
[shrug]
>> So, actually, it's not about try/catch being Java, as try/catch did
>> not originate with Java, as it is about try/catch just not being
>> scalable to wide-spread development.
>
> Can you qualify that statement? What things are impossible?
What's impossible is enforcing and checking that try/catch is used in
a consistent and coherent manner throughout a large body of code, from
multiple developers/sources, such that all the pieces of a large
software project are playing the same game plan.
try/catch *seems* really cool at first, as it localizes the
error-handling to the code doing the work, to some degree, while
allowing a natural semantic for dealing with the errors.
Once you have a non-trivial application, however, the try/catch that
fires, and the error being caught, may have little or nothing to do
with each other, as functions nested in methods wrapped around
functions with methods inside them going umpteen layers deep...
You end up catching somebody else's error and handling it, even though
what you THINK has gone wrong is not at all what actually went wrong,
because they didn't write a try/catch handler where they should have.
E.g.:
You write this nice little bit:
try {
$file = fopen("/some/path/or/other", 'r');
}
catch ($e){
//handle error from opening $file
}
Then, some day soon, somebody splices in this:
try {
if (something($whatever)){
$file = fopen("/some/path/or/other", 'r');
}
}
catch ($e){
//handle error from opening $file
}
Then later on after that (possibly weeks/months/years) some other
programmer (or yourself) changes the 'whatever' function to use
fopen() to open a file, but does NOT wrap that in a try/catch because
it's some silly little file that "has to work"
Well, then it doesn't work one day, for whatever reason, and your
catch handler detects a failure in 'fopen' but it's not the fopen you
think it is, it's the other 'fopen' buried deep in some other function
somewhere else that didn't get caught.
Sure, it's "bad code" -- But it's the kind of "bad code" that
naturally accumulates in a large long-lived project over the years,
rather than some glaring nasty code that you'll refuse to live with,
or fix, or will cause immediate problems in functionality.
At the other end of the telescope, you'll also end up, sooner or
later, with somebody 'catching' an error and doing something with it
that you really really really wish they didn't do -- But you have no
recourse, as their try/catch block is buried deep in the guts of code
you do not want to mess with.
At least, this has been my experience with try/catch.
YMMV.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
