Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20030924125651.70200.qmail@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 24 Sep 2003 08:57:12 -0400
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030807
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Exception behavior question
From: hans@appliedsec.com (Hans Lellelid)

I apologize if this has been asked -- I couldn't find it, if it has.

I am working on a couple os projects for PHP5, and have been building 
with beta1, given that it's a milestone that seems easy for most to 
install, etc.  I have been informed that the Exception class has changed 
significantly in the new snapshots, and wanted to find out what is 
expected at this point when PHP5 goes to release (or beta2, in the 
meantime).

In particular, I'm concerned with getMessage() (and other accessors?) 
being declared final.  In my Exception subclasses, I have been in the 
habit of overriding getMessage() to provide additional information that 
isn't contained in the message attribute.

The reason for overriding getMessage() has to do with another "feature" 
of Exception throwing that feels more like a bug:  if I provide a 
constructor for my Exception subclass, then I lose the automatica 
__FILE__ and __LINE__ that is added by the throw() call.  Specifically, 
the __FILE__ and __LINE__ seems to be set by the Exception constructor, 
so if my subclass looks like:

1
2  class MyException extends Exception {
3	private $moreinfo;
4	function __construct($msg, $moreinfo) {
5		parent::Exception($msg);
6		$this->moreinfo = $moreinfo;
7	}

then getFile() and getLine() will return "MyException.php" and 5, 
respectively.  While I can understand what's happening here, I think it 
would be very nice to allow the throw() to determine the file & line if 
at all possible.  (maybe there is a way that I don't know...?)

So, as I mentioned, I worked around this issue by not using constructors 
in the subclasses, but instead just overriding getMessage() so that it 
could display different information based on what class attributes were 
set (e.g. in addition to error message, the location in XML file of XML 
parsing error).

Anyway, I'd just like to understand where Exception is going so that I 
can minimize the amount of rewrite I'll have to do with upcoming beta 
and production releases.

Thanks-
Hans