Menu
Community /Pin to ProfileBookmark
@NogDogSep 03.2011 — #The "customFunction" is there to illustrate the idea that by extending the Exception class to a sub-class, that sub-class can then be used to implement additional functionality beyond that supplied by the built-in Exception class.
Here's about as simple an example as I can think of, also making use of set_exception_handler() in order to avoid having to do try/catch:
Output:
@NogDogSep 03.2011 — #Like a lot of these things -- especially as you get into OOP PHP -- sometimes you just need to look at it a couple or three different ways until it "clicks" for you. ?@NogDogSep 04.2011 — #I would not recommend that your database class extend an Exception type class, as that is sort of a confusion of responsibilities, and generally you want each class to have a narrow focus. One possibility might be to create sub-classes of Exception if/when desired, using a common method name for your custom exception handler, and check for that method's existence during processing. Your callback function used as a parameter for set_exception_handler() would then either need to be defined separately -- perhaps as part of your general config script -- or as a static method that is part of a utility class. In fact, I might build it into a sub-class of Exception, and then your custom Exception classes would extend that.
CustomException.php:
DBException.php:
DB.php:
sample script:
@NogDogSep 04.2011 — #I created the abstract class CustomException with the idea that it would then be the super-type for any other custom exception class you wanted to define (they would extend CustomException instead of Exception). This way, by defining an abstract custom() method within it (and which, by definition, cannot have a body at that point), all concrete (non-abstract) classes derived from it [i]must[/i] define that method. Therefore, you can know that any object that is_a() CustomException object (has that class as a super-class) will be guaranteed to have a custom() method.
It may seem to be a bit of overkill at this point, but if you think you might ever want to add other specific exception classes that would need to have their own custom() method, you already have everything in place to do so. Certainly it's not the only way (and maybe not even the best), but I figured it was a good illustration of one way to think about it in an OOP way, and followthe dictum to "program to an interface, not to an implementation." ?
Now, after all that philosophy, it may be that you really don't need all that. If all you are concerned about is the error text, you could leave out that abstract class, directly extend the Exception class, and overwrite the __toString() method to get the desired output. ?@NogDogSep 05.2011 — #Firstly, the only purpose to extend Exception is if you want the new class that extends it to do something that Exception does not already do (or do it in a different way). If there is no such need, then don't bother doing it and just throw an Exception object, instead.
Now, as far as all that other OOP inheritance stuff, the concept is that if we know that cass [b]Foo[/b] has a class variable called [b]$bar[/b] and a method called [b]fubar()[/b], then we know that any class that extends [b]Foo[/b] will include those class properties (along with any new properties they may add. So if class [b]New[/b] extends [b]Foo[/b] -- making [b]New[/b] a sub-class of [b]Foo[/b] (and inversely Foo is a super-class of New) -- then we are guaranteed that [b]New[/b] will include that [b]$bar[/b] variable and [b]fubar()[/b] method (regardless of what else it may have had added to it).
Therefore, we can use type-hinting in a function/method parameter specifying that a parameter is a [b]Foo[/b], and the function will allow an object of [b]Foo[/b] [i]or[/i] [b]New[/b] (since it is a sub-class of Foo) and the function will "know" that that object will include that variable and method. Likewise, the is_a() PHP function returns true if the object supplied to it is of the specified class in its second parameter, or is a sub-type extended from the class (or one of its sub-classes, down any number of levels of inheritance).
PS: I will now make my usual recommendation: get a copy of Matt Zandstras's [i]PHP 5 Objects, Patterns, and Practice[/i], read it once, let it digest a bit, then read it again. (You can skip the "Practice" chapters at the end for now, if you want, as they don't strictly deal with OOP concepts.) That book did wonders for helping me "get it." ?
[RESOLVED] help understanding custom exception class?
Can someone please show me a real world example of using this custom exception handling class? [url]http://php.net/manual/en/language.exceptions.extending.php
The example they use is not making sense to me because they are creating a test class with all kinds of extra parameters and constructs in it. And then the examples test the test class instead of testing a try catch block on a real piece of code.
I need a real basic example like if I want to put a function in a try catch that trys to make 2 = 3 and I want the custom handler to return the message “ya big dummy! 2 can’t equal 3!”.
I don’t see them using the “throw new” key words anywhere in the examples and another confusing thing is the customFunction(). What is is for and what goes inside it?
Thanks for any help in understanding this.
Sign in
to post a comment14 Comments(s) ↴
0
@NogDogSep 03.2011 — #The "customFunction" is there to illustrate the idea that by extending the Exception class to a sub-class, that sub-class can then be used to implement additional functionality beyond that supplied by the built-in Exception class.Here's about as simple an example as I can think of, also making use of set_exception_handler() in order to avoid having to do try/catch:
[code=php]
<?php
/**
* Class we'll use to generate an exception
*/
class Foo {
public function bar($a, $b)
{
if($a != $b) {
throw new FooException("$a does not equal $b.");
}
echo "Yes, $a equals $b.";
}
}
/**
* Class to extend Exception so we can use a custom method
*/
class FooException extends Exception
{
public function myCustomMethod()
{
echo "<p class='error'>Hey, dummy! " . $this->message . "!</p>n";
}
}
/**
* Our custom exception-handler
*/
function myExceptionHandler($exception)
{
if(is_a($exception, 'FooException')) {
$exception->myCustomMethod();
}
else {
echo "<p class='error'>Standard Error: " . $exception->message . "</p>n";
}
}
/**
* Put the exception-handler into effect
*/
set_exception_handler('myExceptionHandler');
/**
* Let's see what happens
*/
$test = new Foo();
$test->bar(3, 3);
$test->bar(2, 3);
[/code]Output:
<i>
</i>Yes, 3 equals 3.
Hey, dummy! 2 does not equal 3.!
0
@NogDogSep 03.2011 — #Like a lot of these things -- especially as you get into OOP PHP -- sometimes you just need to look at it a couple or three different ways until it "clicks" for you. ?0
@NogDogSep 04.2011 — #I would not recommend that your database class extend an Exception type class, as that is sort of a confusion of responsibilities, and generally you want each class to have a narrow focus. One possibility might be to create sub-classes of Exception if/when desired, using a common method name for your custom exception handler, and check for that method's existence during processing. Your callback function used as a parameter for set_exception_handler() would then either need to be defined separately -- perhaps as part of your general config script -- or as a static method that is part of a utility class. In fact, I might build it into a sub-class of Exception, and then your custom Exception classes would extend that.CustomException.php:
[code=php]
<?php
abstract class CustomException extends Exception
{
/**
* This method must be defined in each sub-class
* @return string Message to be output by exception handler
*/
public abstract function custom();
/**
* The callback function for set_exception_handler()
*/
public static function handler($e) {
if(is_a($e, 'CustomException')) {
user_error($e->custom());
}
else {
user_error($e->message);
}
}
}
[/code]DBException.php:
[code=php]
<?php
require_once('path/to/CustomException.php');
/**
* The exception class for our DB class
*/
class DBException extends CustomException
{
public function custom()
{
return ("Hey! You can't do that! Stop it!<br />nERROR: " . $this->message);
}
}
[/code]DB.php:
[code=php]
<?php
require_once('path/to/CustomException.php');
/**
* The DB class
*/
class DB extends mysqli
{
public function testException()
{
throw new DBException("This is a test.");
}
}
[/code]sample script:
[code=php]
<?php
require_once('path/to/DB.php'); // will include our Exception classes, too, in this case
// notice use of array() to specify class::method as the callback function:
set_exception_handler(array('CustomException', 'handler'));
$test = new DB('localhost', '####', '####');
$test->testException();
[/code]0
@NogDogSep 04.2011 — #I created the abstract class CustomException with the idea that it would then be the super-type for any other custom exception class you wanted to define (they would extend CustomException instead of Exception). This way, by defining an abstract custom() method within it (and which, by definition, cannot have a body at that point), all concrete (non-abstract) classes derived from it [i]must[/i] define that method. Therefore, you can know that any object that is_a() CustomException object (has that class as a super-class) will be guaranteed to have a custom() method.It may seem to be a bit of overkill at this point, but if you think you might ever want to add other specific exception classes that would need to have their own custom() method, you already have everything in place to do so. Certainly it's not the only way (and maybe not even the best), but I figured it was a good illustration of one way to think about it in an OOP way, and follow
Now, after all that philosophy, it may be that you really don't need all that. If all you are concerned about is the error text, you could leave out that abstract class, directly extend the Exception class, and overwrite the __toString() method to get the desired output. ?
0
@NogDogSep 05.2011 — #Firstly, the only purpose to extend Exception is if you want the new class that extends it to do something that Exception does not already do (or do it in a different way). If there is no such need, then don't bother doing it and just throw an Exception object, instead.Now, as far as all that other OOP inheritance stuff, the concept is that if we know that cass [b]Foo[/b] has a class variable called [b]$bar[/b] and a method called [b]fubar()[/b], then we know that any class that extends [b]Foo[/b] will include those class properties (along with any new properties they may add. So if class [b]New[/b] extends [b]Foo[/b] -- making [b]New[/b] a sub-class of [b]Foo[/b] (and inversely Foo is a super-class of New) -- then we are guaranteed that [b]New[/b] will include that [b]$bar[/b] variable and [b]fubar()[/b] method (regardless of what else it may have had added to it).
Therefore, we can use type-hinting in a function/method parameter specifying that a parameter is a [b]Foo[/b], and the function will allow an object of [b]Foo[/b] [i]or[/i] [b]New[/b] (since it is a sub-class of Foo) and the function will "know" that that object will include that variable and method. Likewise, the is_a() PHP function returns true if the object supplied to it is of the specified class in its second parameter, or is a sub-type extended from the class (or one of its sub-classes, down any number of levels of inheritance).
PS: I will now make my usual recommendation: get a copy of Matt Zandstras's [i]PHP 5 Objects, Patterns, and Practice[/i], read it once, let it digest a bit, then read it again. (You can skip the "Practice" chapters at the end for now, if you want, as they don't strictly deal with OOP concepts.) That book did wonders for helping me "get it." ?