php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #39615 Exception code can not be string
Submitted: 2006-11-24 11:33 UTC Modified: 2021-01-21 14:31 UTC
Votes:19
Avg. Score:3.6 ± 1.0
Reproduced:13 of 13 (100.0%)
Same Version:4 (30.8%)
Same OS:7 (53.8%)
From: marcos dot neves at gmail dot com Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: * OS: *
Private report: No CVE-ID: None
 [2006-11-24 11:33 UTC] marcos dot neves at gmail dot com
Description:
------------
The follow code is ok, cause 123, even as a string, it can be convert to number.
new Exception("Message", "123");

The follow is not ok.
new Exception("Message", "NotNumber");

PHP is not a typed language, why Exception must have a number as code?

The problem is that error code doesn?t means "Number error code" but could be a string error code, like mysql 5.1 uses.

Check the follow reproduce able code.

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

error_reporting(E_ALL);

$host = "localhost";
$dbName = "test";
$user = "root";
$passwd = "";
$mysqlDsn = "mysql:host=$host;$dbName";

$pdo = new PDO($mysqlDsn, $user, $passwd);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try {
	$pdo->query("SELECT version");
}catch(Exception $e){
	$code = $e->getCode(); // 42S22
	echo "<pre>";
	var_dump($code); // string(5) "42S22"
	throw new Exception($e->getMessage(), $code);
}

?>

Expected result:
----------------
The follow line, should accept the $code var, but doesn?t.
throw new Exception($e->getMessage(), $code);

It?s not consistent, since the Exception object constructor can?t accept a non number as code, but it can return.

See:

$msg = $catchedPdoMysqlException->getMessage();
$code = $catchedPdoMysqlException->getCode();

new Exception($msg, $code); // $code is not valid one.

Actual result:
--------------
Exception code, should accept non numbers as a code value, as mysql does.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-08-04 05:22 UTC] bryan at ravensight dot org
Ubuntu 10.04.1 LTS \n \l
PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 2010 20:01:00) 
MySQL Server version: 5.1.41-3ubuntu12.5 (Ubuntu)

When executing a statement which generates:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '{REDACTED}' for key 'PRIMARY'

The following test does not pass when the exception is caught:

if ($exception->getCode() === 23000)

However, the following code DOES pass when the exception is caught:

if ((int)$exception->getCode() === 23000)

The API documentation for getCode() states that it returns an integer and that is clearly not the case in this example.

I merely request that the function and the documentation be consistent.
 [2011-01-01 23:40 UTC] jani@php.net
-Summary: Exception code cant be string +Summary: Exception code can not be string -Package: Feature/Change Request +Package: Scripting Engine problem -Operating System: ANY +Operating System: *
 [2011-04-25 18:41 UTC] bandy dot chris at gmail dot com
Related to bug 51742.

Allowing a non-numeric $code in the Exception constructor seems like the right solution.
 [2015-06-06 16:08 UTC] cmb@php.net
-PHP Version: 5.2.0 +PHP Version: *
 [2015-06-06 16:08 UTC] cmb@php.net
> Allowing a non-numeric $code in the Exception constructor seems
> like the right solution.

That might constitute a considerable BC break, and would probably
require an RFC.
 [2021-01-21 14:31 UTC] cmb@php.net
-Status: Open +Status: Suspended
 [2021-01-21 14:31 UTC] cmb@php.net
It makes no sense to leave this unresolved for another five years,
so for the time being, I'm suspending this ticket.  If anybody is
still interested in this feature, please pursue the RFC
process[1].

Also note that it is already possible to store *arbitrary* values
in the ::$code property of own exception types[1].

[1] <https://wiki.php.net/rfc/howto>
[2] <https://3v4l.org/KdCAm>
 [2021-05-26 18:36 UTC] corepet696 at geekale dot com
@cmb what a lame excuse to dodge a bullet, don't you think?

Accessing directly the protected $code to bypass its wrong specification sounds like a bad design pattern. 

RFC, really?

I understand this might be acceptable to PHP programmers since PHP is a garbage language, but let's be real, it's completely wrong.

Yeah sure lets just clean the dust by hiding under the carpet and move on.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 30 17:01:29 2024 UTC