Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_default_classes.c zend_default_classes.h zend_execute.h zend_execute_API.c

On Tue, 2004-02-17 at 00:24, Hans Lellelid wrote:

If I understand correctly, PHP 5 uses an unchecked exception implementation (functions are not required to declare what exceptions they throw). I very much agree that unchecked exceptions are the preferred way to handle things, however ideally I do not think they should be the only way. I think there is value in a checked exception and that being able to define an exception that would not be generically caught by a "catch (Exception $e)" is a good thing. In fact *I* think using a catch all should generate a compiler warning. ;) Instead I think exceptions that are not specifically handled should pass up through the code and into the PHP engine. There they can be caught and the application can handle them like any other error through set_error_handler(). How is that any less useful than "catch (Exception $e) {echo $e->getMessage()}"? In fact, I think it is more useful because it more appropriately reflects the context that the error is being handled in; something has gone terribly wrong and I don't know what to do to fix it. Clearly the programmer is not handling these exceptions explicitly in their code. Additionally, the error_handler prototype can be passed the exception object so that the information is available. To me exceptions are useful for one reason: context. First of all they hold more flexibility over trigger_error(). By creating custom Exception classes (either by extending the Exception class or making a new base exception class) you can provide additional context about the error. In languages that have exceptions I never extend the default classes unless I find it necessary to do so. For example, if I can handle all my exceptions using the default classes in Java I will. I see a lot of discussion here of ways to let people use catch all statements, not handle exceptions, group exceptions into certain keyholes, etc. To me this is a bad thing and something that is done all too often with exceptions and only causes problems. Often it is a result of exceptions being used in-appropriately in the fist place. All that being said, I'll say again that I am against complicating exceptions any further in PHP. In fact the more I think about it I become convinced PHP should at least not require exceptions be used in the same way it does not force programmers to write OO code. Part of why I love PHP is its simplicity and similarity to C. I am thoroughly enjoying the OO additions to PHP and lately have been taking great advantage of it. Conversely, I don't think the majority of PHP users use or want to use classes, much less want to learn about using exceptions properly. Here are some resources a quick search turned up that might be useful in explaining my thoughts this time: General Exception stuff: http://c2.com/cgi/wiki?UseExceptionsInsteadOfErrorValues This is a great resource, some of the links off this page are also very useful. Java based resources, obvious differences should be kept in mind: http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html Exception "best practices" in Java. http://www.hutteman.com/weblog/2003/08/31-118.html A good description of the importance of using unchecked exceptions. http://www.darrenhobbs.com/archives/000411.html He has a great perspective on checked exceptions. http://www.soletta.com/categories/javaEtc/2003/08/27.html#a324 Just another perspective to ponder. :) Regards, Adam

Hello Ard, Monday, February 16, 2004, 9:51:51 PM, you wrote:

You are wrong. The point is i am not willing to risc unstabilites with exceptions. This is a special class that heavily interacts with the executor and facilities used even after exceution hence i must be sure several intenal properties are in an exact and intact form at 100%.

No those are read access members to private property members. When you lok at the exception class: php -r 'reflection_class::export("exception");' then you'll encounter that you can overload __toString() and the __construct(). Or in other words you should use 'print $e' or '(string)$e' or '$e->__toString()'.

== Quote from Derick Rethans (derick@php.net)'s article

The problem is not the name, but the fact that some people would like to have an interface as the exception base hierarchy. "Throwable" was first proposed, but some people considered it was too Java oriented. We could also have this interface named "Exception" and the PHP class implementation "PhpException" .... Personally I don't like interfaces start with an 'I'. I would also prefer "Error" instead of "Exception" because I consider what we get is an error, exception is just the mechanism to report errors. Stephane