# [EMAIL PROTECTED] / 2007-01-04 16:34:46 -0600:
> On Wed, January 3, 2007 3:43 pm, Roman Neuhauser wrote:
> That __toString magic didn't even exist in earlier versions, and has
> already changed out from under you once, right?...
The whole program depends on the syntax and semantics of PHP 5.1, and
the fact that something hasn't changed for a long time means nothing
in this language. :)
> So which one really makes sense to use for robust code? :-)
> [shrug]
The one that's easier to maintain: faster to read, simpler to grok.
> 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.
Yeah, that can lead to unexpected behavior. It still helps prevent
crashes.
> 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"
Ok, but what harm has been done? something() presumably did the fopen()
for a reason, and couldn't work without the file handle and couldn't
succeed anyway.
Sure, the program leaves the normal path at this moment unexpectedly,
and I can understand your frustration, but it has a bug, right? And
although the program contains a bug it hasn't crashed, it just entered
whatever orderly cleanup-and-exit path you had prepared.
If fopen() didn't throw and the programmer didn't check the return value
(catch the exception in your version), you'd be screwed not even knowing
it.
I think you brought a solid example of superiority of exceptions over
returning error codes.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
