Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0a1

Bug #9151 ReflectionException when documenting classes derived from PHP internal classes
Submitted: 2006-10-24 15:11 UTC
From: netmaster at bison-soft dot de Assigned: ashnazg
Status: Closed Package: PhpDocumentor (version 1.3.1)
PHP Version: 5_2 CVS-2006-10-24 OS: linux 2.4 (RHEL 3)
Roadmaps: 1.3.2    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 22 + 15 = ?

 
 [2006-10-24 15:11 UTC] netmaster at bison-soft dot de (Helmut)
Description: ------------ When trying to document a class derived from the internal class "Exception" v1.3.0 throws following exception: Writing ./docs/__filesource/fsource_Rde__RdeBaseException.php.html Procedural Page Elements... Classes...PHP Fatal error: Uncaught exception 'ReflectionException' with message 'Cannot determine default value for internal functions' in /usr/lib/php/pear/PhpDocumentor/phpDocumentor/ParserElements.inc:1735 Stack trace: #0 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/ParserElements.inc(1735): ReflectionParameter->getDefaultValue() #1 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/Converter.inc(4720): parserMethod->getOverrides(Object(HTMLframesConverter)) #2 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/Converter.inc(4140): Converter->getFormattedOverrides(Object(parserMethod)) #3 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/Converters/HTML/frames/HTMLframesConverter.inc(1070): Converter->convertMethod(Object(parserMethod), Array) #4 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/Converter.inc(3970): HTMLframesConverter->convertMethod(Object(parserMethod)) #5 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/Converter.inc(1920): Converter->Convert(Object(parserMethod)) #6 /usr/lib/php/pear/PhpDocumentor/phpDocumentor/IntermediateParser. in /usr/lib/php/pear/PhpDocumentor/phpDocumentor/ParserElements.inc on line 1735

Comments

 [2006-10-24 16:01 UTC] netmaster at bison-soft dot de
As a quick workaround i've added following try/catch arround the offending source line in ParserElements.inc which solves the problem for me (but i can't guaranty that this leads to expected results in all circumstances): try { $value = $param->isOptional() ? var_export($param->getDefaultValue(), true) : null; } catch (Exception $e) { $value = null; }
 [2006-12-04 14:36 UTC] patrice dot pillot at asm dot map dot archi dot fr (phep)
I experienced the same bug here today. The workaround works here too. Since I experimented this bug right after upgrading from php 5.1.6 to php 5.2, I strongly suspect it has something to do with this upgrade (debian etch). Note also the following lines, just before the stack trace : Converting /path/src/myapp/myfwk/lib/BF_Exception.class.phpWARNING: class BF_Exception in package myfwk parent not found in @see parent::__construct() Writing phpdocs/__filesource/fsource_myfwk_framework_myappmyfwklibBF_Exception.class.php.html WARNING: class BF_Exception in package myfwk parent not found in @see parent::__construct() Could it be that PhpDoc is looking for the source file of php base exception class (since class BF_Exception extends Exception) which would undoubtedly be doomed to fail, wouldn't it ? Oh, by the way, I don't myself use the @see tag (there), it's coming out from phpdoc internals...
 [2006-12-12 20:42 UTC] zippy1981 at gmail dot com (Justin Dearing)
Below is the patch for me. I had to deal with exceptions in 3 places. I only catch ReflectionExceptions. --- ParserElements.inc.orig 2006-12-12 14:48:32.000000000 -0500 +++ ParserElements.inc 2006-12-12 14:53:58.000000000 -0500 @@ -1098,7 +1098,11 @@ } $doc = new parserDocBlock; foreach ($method->getParameters() as $param) { - $value = $param->isDefaultValueAvailable() ? var_export($param->getDefaultValue(), true) : null; + try { + $value = $param->isDefaultValueAvailable() ? var_export($param->getDefaultValue(), true) : null; + } catch (ReflectionException $e) { + $value = null; + } if ($param->isPassedByReference()) { $var->addParam('&$' . $param->getName(), $value, $param->isOptional(), $param->getClass()); @@ -1732,7 +1736,11 @@ } $doc = new parserDocBlock; foreach ($method->getParameters() as $param) { - $value = $param->isOptional() ? var_export($param->getDefaultValue(), true) : null; + try { + $value = $param->isOptional() ? var_export($param->getDefaultValue(), true) : null; + } catch (ReflectionException $e) { + $value = null; + } if ($param->isPassedByReference()) { $var->addParam('&$' . $param->getName(), $value, $param->isOptional(), $param->getClass()); @@ -1852,7 +1860,11 @@ } $doc = new parserDocBlock; foreach ($method->getParameters() as $param) { - $value = $param->isOptional() ? var_export($param->getDefaultValue(), true) : null; + try { + $value = $param->isOptional() ? var_export($param->getDefaultValue(), true) : null; + } catch (ReflectionException $e) { + $value = null; + } if ($param->isPassedByReference()) { $var->addParam('&$' . $param->getName(), $value, $param->isOptional(), $param->getClass()); @@ -2275,4 +2287,4 @@ } } -?> \ No newline at end of file +?>
 [2006-12-12 23:19 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2006-12-15 20:55 UTC] ashnazg at php dot net (Chuck Burgess)
Does this scenario imply that any internal PHP classes that are NEW WITH PHP5 need to somehow be set up as "mock objects" at the beginning of a phpdoc run that recognizes it is running against PHP4? Or, should phpdoc be treating ANY missing internal classes (like the base Exception class would be in PHP4) just like any other non-internal class would be treated... with a note in the errors.html file saying "hey dude, you extended the Exception class, but I couldn't find it"... ??
 [2006-12-15 23:48 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2006-12-19 16:22 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2006-12-20 06:22 UTC] zippy1981 at gmail dot com (Justin Dearing)
Greg, I am using this with version 1.3.1. I understand how you would not want to break PHP4 compatability. It just never occured to me try/catch was a PHP5 thing. I'll see if can figure ou something php4/5 compatiable.
 [2007-01-18 16:35 UTC] ashnazg at php dot net (Chuck Burgess)
Would a custom wrapper function be an ugly way to handle this? Something that you could use to wrap a "trouble-maker" function, that would itself figure out if try/catch is available in the PHP environment, and use some other means of accomplishing the try/catch concept if it's not available? Then again, if there was an obvious alternative to try/catch, I suppose someone would have already mentioned it... I guess I could step back a moment and ask if someone's already tested this scenario against the stable 5.2 release... ?
 [2007-01-18 16:44 UTC] ashnazg at php dot net (Chuck Burgess)
Could someone hook me up with a test file that triggers this problem? I'd like to set up a v1.3.1-on-v5.2.0 setup and work on some ideas, but I need a testfile that is known to trigger this error (rather than trying to divine one myself with my Y-shaped stick).
 [2007-02-09 12:45 UTC] bigtree at donotspam dot 29a dot nl
This will do to reproduce the bug: <?php class MyException extends Exception { public function __construct () { } } ?> Throws the following error (PHP 5.2.1): Fatal error: Uncaught exception 'ReflectionException' with message 'Cannot determine default value for internal functions' in (...)/PhpDocumentor/phpDocumentor/ParserElements.inc:1735 Without __construct(), no exception gets thrown.
 [2007-02-09 13:13 UTC] bigtree at donotspam dot 29a dot nl
Replacing line 1735 with: $value = ($param->isOptional() && !$method->isInternal()) ? var_export($param->getDefaultValue(), true) : null; Prevents the exception being thrown (without try-catch logic). Maybe log an error 'Cannot determine default value for builtin method' when checking for internal parameters?
 [2007-02-15 13:50 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send
MANUAL CONFIRMATION IS NOT POSSIBLE.  Write a message to pear-dev@lists.php.net
to request the confirmation link.  All bugs/comments/patches associated with this

email address will be deleted within 48 hours if the account request is not confirmed!
 [2007-02-15 16:54 UTC] ashnazg at php dot net (Chuck Burgess)
I've tested that one-line change to ParserElements.inc against that small test file MyException.class.php, and I do see that running v1.3.1 against PHP v5.2.0 does avoid it from crashing. The output doc looks fine, cleanly showing that Exception is the parent. It runs clean against PHP v5.1.6 and v4.4.4 also. I'm going to test it now against PhpDoc's CVS HEAD, documenting the PhpDoc codebase itself, as a large-scale test of the patch.
 [2007-02-15 17:15 UTC] ashnazg at php dot net (Chuck Burgess)
This patch seems to be safe on the CVS Head. "netmaster", "patrice", and "zippy1981", are you able to try that one-line patch against the codebases you are each documenting, to see if it solves the problems for each of you cleanly?
 [2007-02-15 21:30 UTC] patrice dot pillot at teletopie dot net (phep)
This one-line fix works here. Thanks a lot !
 [2007-02-16 19:49 UTC] ashnazg at php dot net (Chuck Burgess)
This bug has also been recently reported on Sourceforge (#1656902). I have attached a patch file there containing bigtree's one-line fix.
 [2007-02-20 14:32 UTC] ashnazg at php dot net (Chuck Burgess)
Fix ok'd by Greg, committed to CVS.