On Sun, December 23, 2007 3:50 pm, Martin Alterisio wrote: > It's not supposed to be practical, it's just a way to handle errors. > You > shouldn't rely on try/catch for algorithm implementation. > > You create exceptions for errors and unexpected behavior. Then in some > other > part of the system you use try/catch to prevent the code from > terminating > abruptly. You catch the exception (you should know which exceptions > can be > thrown), and act accordingly. Either closing resources, add a log > message > with debug information, and/or sending an error message to the user. Except that once you start trying to integrate several large bodies of code, you have NO IDEA what exceptions can be thrown, and even less idea where they didn't get caught and handled properly. Worse, many times the library[ies] you are integrating to an abysmal job of doing anyting intelligent with the catch block, and you're stuck with something even worse than set_error_handler. try/catch works great for small/medium projects, or even large well-documented projects perhaps, but as soon as you start trying to integrate several projects... Well, in MY experience, try/catch just ended up biting me in the butt... ymmv naiaa ianal -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/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