Hello Tobias, Monday, August 8, 2005, 3:35:28 PM, you wrote:
> Hi Johannes Schlueter! > On 08/08/05 14:50 you wrote: >>>> The throw an Exception when SPL disabled and an InvalidArgumentException >>>> when it is enabled. >>>That's senseless when writing applications that shall be version >>>independant. Just sticking to Exception should be fine. >> No it is not, in your application you can still simply catch Exception to be >> independent of SPL since the InvalidArgumentException class extends the >> Exception class. But by using nested Exceptions you can catch them >> independently. Else you would have to catch every Exception, parse the error >> message or trace to see wether it was a problem while calling the >> function/method or some code inside the function/method went wrong. > The point is, that it's senseless to have it throw any exception that > can be disabled, when you want to write portable applications. In that > case you still have to stick to catch Exception and have no benefit of > it throwing anything else, when SPL is enabled. > I would pretty much appreciate it having thrown an > InvalidArgumentException, but then this should work everywhere. If you plan to support PHP builds without SPL then that most likley means that you have dropped other built-in default extensions too. Probably because of their memory space to reduce loading time. In that case you are not up for portability or have made a major mistake already in the beginning. Anyway there is no argument here. If you go for portable apps in the sense that any extension can be diabled then catching plain Exceptions should be more than good enough. You cannot expect to have full blown oo support when you disable the one oo extension. As a side note we could probably also move all exception declarations from SPL to the engine but then we'd loose the possibility to support builds without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. best regards marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
