On Thu, January 4, 2007 8:26 pm, Roman Neuhauser wrote: > # ceo@xxxxxxxxx / 2007-01-04 18:45:07 -0600: >> On Thu, January 4, 2007 6:17 pm, Roman Neuhauser wrote: >> > 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. >> >> over returning error codes and not DOING anything with them? Sure. >> >> Over well-written code that does something with the returned error >> codes? no. Just a stylistic difference really, if all developers >> consistently did their error-checking, and did it fairly well. >> >> Alas, they don't. > > That's exactly the point. Programmers don't check return values, > programs have bugs. Programmers don't write try/catch blocks, programs have bugs. Same thing, different spelling. >> And, suppose it's NOT an fopen() that was the problem deep in the >> guts >> of the other guy's code. >> >> Now you are catching an error and you have NO IDEA what the [bleep] >> to >> do with it. > > If you really don't know what to do, then the right thing is probably > an > orderly exit of the application, no? What I should have said is that you are catching an error assuming that it is caused by X when it is caused by Y, and handling it inappropriately, because you cannot tell the difference between the errors you meant to catch, and the lower-level un-caught errors. >> At least with error code returns, you are USUALLY dealing with a >> specific way to get those codes (in PHP, not C-style shell-style >> pass-the-buck error code bubble-up). > > With error codes, you are USUALLY dealing with crashes and wrong > behavior. Compiled programs segfault, programs in PHP produce > unspecified numbers of E_NOTICE, E_WARNING, and quite easily drop dead > with an E_FATAL before returning to where you'd be complaining that > you > don't know what to do with the error! I know exactly what to do with those errors in set_error_handler. :-) >> And, of course, you just ignored the question of another catch block >> doing something you wish it didn't do... > > I don't know what that means. I don't know how else to describe it, but will make one last stab: Pretend you are using some library of software with a lot of code, and you have a lot of your own code. There are try/catch blocks all over the place. The library does something with try/catch, and you don't like the way it handles the error. It's very difficult to change that behaviour. -- 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
