Hi,

do you guys use typehinting, if so: why is it useful to you?

I found that while it produces a "catchable fatal error", this error, in fact, can not be caught in a try/catch block.

When I code a simple check and an exception myself I actually CAN catch it...which seems a better approach, what do you think?

(Here is what the guys at php.net have to say about it: linkage

Which imnsho is missing the point. If it is called "catchable" it should be or if it shouldn't be catchable, then it shouldn't be called so.)

Example:

<?php

$tht = new TypeHintingTest;
try {
	$tht->setMyHintedVar(5); //so called "catchable exception" is thrown, but catch block won't get executed
	echo $tht->getMyHintedVar(); //property is even set to 5 and code execution continues!
	$tht->setMyStandardVar(5); //as intended, execution is transferred to catch block
	echo $tht->getMyStandardVar(); //this won't execute
} catch (Exception $e) {
	throw new exception($e->getMessage()); //just passing it on to the debugger
	exit;
}

class TypeHintingTest
{
	private $_myHintedVar = null;
	private $_myStandardVar = null;

public function setMyHintedVar(mysqli $mysqli)
{
	$this->_myHintedVar = $mysqli;
}

public function getMyHintedVar()
{
	return $this->_myHintedVar;
}

public function setMyStandardVar($mysqli)
{
	if ($mysqli instanceof mysqli) {
		$this->_myStandardVar = $mysqli;
	} else {
		throw new exception ('Parameter of wrong type. Expected instance of mysqli, got ' . gettype($mysqli));
	}
}

public function getMyStandardVar()
{
	return $this->_myStandardVar;
}
}
?>

Bjom

    Bjom wrote:

    I found that while it produces a "catchable fatal error", this error, in fact, can not be caught in a try/catch block.

    A "catchable fatal error" is not an exception, but a recoverable error that can be handled by an error handler set with [man]set_error_handler/man.

      hum... now that you say it: error != exception :o

      Anyway: I would have expected that it bubbles up with the try/catch....obviously I was wrong.

      set_error_handler() seems so PHP 4ish :/

      thx for the reply

      P.S: do you use typehinting yourself at all?

      Bjom

        Bjom wrote:

        do you use typehinting yourself at all?

        Yes, but I never actually tried setting an error handler. It seems to me that such an error is a logic error, not a runtime error, and should by right never happen.

          Yes, unless you have other ppl using your classes, then you can't be too careful.

            But then it's their job to handle their errors.

              ...maybe I'm missing the point here...

              Exception is but a wrapper class for errors isn't it? Thus no matter if it is productiontime or runtime error, it's possible to deal with it via exceptions simply for comforts sake.

              Three things still bother me about this typehinting behavior:

              1. I do typehinting for a reason. So the least I expected was that if a wrong type somehow gets in, then the parameter will NOT get set, but rather stay what it was (in the above case NULL).

              2. calling the error "catchable" a bit of a misnomer, since it is misleading --> handleable might sound bad, but would be correct (or change the function name to set_error_catcher() :p)

              3. Why o why isn't it so that an exception thrown in any case an error occurs?

              Bjom

                Bjom wrote:

                Exception is but a wrapper class for errors isn't it? Thus no matter if it is productiontime or runtime error, it's possible to deal with it via exceptions simply for comforts sake.

                I would not really describe exceptions that way, but yes, exceptions are meant to report exceptional conditions that constitute error conditions of some sort.

                Bjom wrote:

                1. I do typehinting for a reason. So the least I expected was that if a wrong type somehow gets in, then the parameter will NOT get set, but rather stay what it was (in the above case NULL).

                Without type hinting, you would get a fatal error due to say, an attempt to call a method that does not exist. For me, type hinting is a way to make my intentions explicit and to make the error message more obvious. If a type violation occurs for a script that is live, I think that the best one can do is to log the error and have it fixed. If an exception is thrown, what can be done in the handler other than to log? Maybe you could display a nice error message to the user rather than a (white?) screen of death, and perhaps this is why the error is "catchable".

                Bjom wrote:

                2. calling the error "catchable" a bit of a misnomer, since it is misleading --> handleable might sound bad, but would be correct

                I agree. I think that they should have called it "recoverable" since that is the name of the corresponding defined error constant. On the other hand, "recoverable fatal error" sounds like an oxymoron.

                Bjom wrote:

                3. Why o why isn't it so that an exception thrown in any case an error occurs?

                I suspect that backward compatibility is at work here in many cases. That said, it turns out that ErrorException can be used in conjunction with set_error_handler() to get errors translated into exceptions.

                  laserlight wrote:

                  On the other hand, "recoverable fatal error" sounds like an oxymoron.

                  "Recoverable error" would be enough: ordinary errors (as opposed to warnings or notices) are fatal anyway.

                    Write a Reply...