php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #34538 Implementation issue: getMessage() in SPLs Exception
Submitted: 2005-09-17 18:40 UTC Modified: 2005-09-18 14:38 UTC
From: ts at siteartwork dot de Assigned: helly (profile)
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.* OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ts at siteartwork dot de
New email:
PHP Version: OS:

 

 [2005-09-17 18:40 UTC] ts at siteartwork dot de
Description:
------------
The declaration of getMessage() as final in the SPLs Exception class makes it impossible to encapsulate other (Userland-)Exceptions and provide appropriate functionality.


Reproduce code:
---------------
<?php

class UserException extends Exception {

private $encapsulatedException = null;

public function __construct($message = null, $e = null)
{
    if ($e !== null && ($e instanceof Exception) {
    $this->encapsulatedException = $e;
    } else {
   $this->encapsulatedException = null;
 
}
    parent::__construct($message);
}

public function getMessage()
{
   $message = parent::getMessage();
    if ($message == null && $this->encapsulatedException !== null) {
    echo $this->encapsulatedException->getMessage();
}
}

}

?>

Expected result:
----------------
It should be possible to override the getMessage()-method to decide wether to return the message the object was instantiated with or the message of the encapsulated Exception.

Actual result:
--------------
Fatal error: Cannot override final method Exception::getMessage() 

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-18 13:16 UTC] helly@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Exceptions are write once (constructor) and read multiple (access methods). This is necessary because a missuse might otherwise most likely result in an immediate SEGV or even worse a security issue.

But anyway is the need to overwrite information passed along with an exception a sign for a design flaw. Exceptions are not meant to transport parameters. In general follow these rules:
1) Exceptions are Exceptions
2) Never Exceptions for control flow
3) Never ever use Exceptions for parameter passing

 [2005-09-18 14:38 UTC] ts at siteartwork dot de
>Thank you for taking the time to write to us, but this is >not
I did mark it as a feature-request, so I thought it would be okay.

>[...]

I've seen this concept in other languages (the need to wrap another exception to "assimilate" it) but I know that the howto of exceptions are often discussed, so I won't argue and accept your decision. Thx for your reply!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed Jan 15 09:01:28 2025 UTC