2007/12/31, Richard Lynch <ceo@xxxxxxxxx>: > > 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 > > You made me realize that I hadn't thought much on the subject. Now I understand the benefits of how Java integrates exceptions more tightly into system design. Maybe it would be a good idea to assimilate those features. The features I'm referring to is the declaration of exceptions thrown by a function. If you use a function that declares throwing exceptions and don't use a corresponding try/catch around it, the compile will fail because you're not handling the exceptions. You can either use a try/catch or forward the exception by declaring that you will also throw exceptions. Adding these features to PHP is, I think, not possible (compile-time php doesn't know what will be the extent of the system at runtime). But you can use a code analyzer that would parse metadata, such as the one used for doc-comments, and flag this problems before putting the code into production.
