- Joined
- 11 yrs. 6 mth. 27 days
- Messages
- 5,381
- Reaction score
- 18,380
- Age
- 45
- Wallet
- 11,590$
- [email protected]
Introduction:
The title pretty much explains the purpose of try, throw and catch blocks. Most basically said, they handle specified errors upon their occurrence. We are also enabled to specify the error that should be output. We dispose with three main blocks which are not used independently from each other.
Try
- The block that 'listens' for any thrown exceptions
Throw
- If any, the Throw block sends them to the Try block
Catch
- Catch block receives what the Try block has sentFirst of all, I'd like to start off with some common ways which programmers use to return their errors and meanwhile explain the mechanism of try, throw, catch. As usual with our example. We have one class UserModel (UserModel.php) which supposedly would be the model of a user and one public method which takes a couple of parameters and registers them on the database.
And we have our index.php which handles that data by some default values assigned beforehand and includes the UserModel.php file.
The first thing we should do in such case is to validate the incoming data because the model itself is an independent unit and without any validation, you can kinda imagine what can really happen. And an independent unit would mean that the model won't be disturbed by whether someone calls it or not.
We have a simple loop to check for the length of the name, if the name is above 4 characters it return boolean true, if not boolean false. From the model point of view, there's nothing wrong to code it like that. But from the point of view of the whole code and the programmer who calls this method, this is not practical. For example, when he gets returned boolean false, means that something has gone wrong but if we have like more than one if statements or any loop checks and use true and false as return values, the coder won't be able to find out where the improper input has been used. Take for instance the following:
So basically with all those boolean values we are unable to identify the input that is not acceptable. Now the next thing that people use to do in such cases is to return specific messages.
In small projects or any tiny pieces of code that do not require any solid validation and sanitize of the input, this scheme is okay. But do be perfectly strict and accurate and actually practical whereas returning strings of data, we would have some public static properties and we will actually return the identifier of that public static property. However, that is not the idea of this tutorial so I won't get into that now.
So the thing that is not practical with the above example is that the programmer should write a series of loops so as to describe every situation that may occur. The second thing that is not practical about it is its so-called impact on the semantics. Now what does that mean? It means that the public method register is not supposed to return the errors within itself. As a method, it is not his job to handle the errors but in this case to register the user.
So to the essence of this tutorial:
We throw an exception using the Throw block. It's literally nothing more than an ordinary class, the difference is that it is embedded in PHP and we do not need to write a file for it and so on. The first check does not pass because the string 'Keeper' has more than 4 characters. Upon executing this code we are returned with an error stating the following:
As I said in the introduction, the job of the Try segment (block) is to listen if anything between its scope throws and exception. If so, it sends it to the Catch block. Otherwise, if there is nothing wrong, no error is being returned as if the catch block does not exist.
The Catch block will be executed automatically only if any of these codes throw an exception. Catch accepts one parameter called $exc. It comes from exception and it's practically one regular object which has a few embedded methods for itself. They are:__toString();
- A magic method which represents an exception as a string value. It accepts no parameters therefore
getCode();
- Takes the exception code (the parameter for the code in the exception is obligatory). It accepts no parameters as well
getFile();
- Gets the file in which the exception has occurred
getLine();
- Gets the line in which the exception has occurred
getMessage();
- Grabs the exception message
getPrevious();
- Used to return the previous exception (if any) - not an obligatory parameter of the exception class
getTrace();
- Not sure really. Read it on php.net - I never came to use this one
getTraceAsString();
- Does the same as getTrace but converts the value to a stringNotice that Throw always works with objects which are exceptions. For example executing the class using getLine(); will output the line where the error has occurred. In this case it will be 13. If we use getFile(); it will respectively return the file where it has occurred and so on. I have explained them above.
In some specific cases, Try, Throw, Catch comes in handy mainly because of its flexibility. First, we listen for whatever exception there might occur, no matter where it has occurred.
As of our Catch block situations in our code, you need to be aware that their sequence of writing is important. So take that in mind as well.
The title pretty much explains the purpose of try, throw and catch blocks. Most basically said, they handle specified errors upon their occurrence. We are also enabled to specify the error that should be output. We dispose with three main blocks which are not used independently from each other.
Try
- The block that 'listens' for any thrown exceptions
Throw
- If any, the Throw block sends them to the Try block
Catch
- Catch block receives what the Try block has sentFirst of all, I'd like to start off with some common ways which programmers use to return their errors and meanwhile explain the mechanism of try, throw, catch. As usual with our example. We have one class UserModel (UserModel.php) which supposedly would be the model of a user and one public method which takes a couple of parameters and registers them on the database.
And we have our index.php which handles that data by some default values assigned beforehand and includes the UserModel.php file.
The first thing we should do in such case is to validate the incoming data because the model itself is an independent unit and without any validation, you can kinda imagine what can really happen. And an independent unit would mean that the model won't be disturbed by whether someone calls it or not.
We have a simple loop to check for the length of the name, if the name is above 4 characters it return boolean true, if not boolean false. From the model point of view, there's nothing wrong to code it like that. But from the point of view of the whole code and the programmer who calls this method, this is not practical. For example, when he gets returned boolean false, means that something has gone wrong but if we have like more than one if statements or any loop checks and use true and false as return values, the coder won't be able to find out where the improper input has been used. Take for instance the following:
So basically with all those boolean values we are unable to identify the input that is not acceptable. Now the next thing that people use to do in such cases is to return specific messages.
In small projects or any tiny pieces of code that do not require any solid validation and sanitize of the input, this scheme is okay. But do be perfectly strict and accurate and actually practical whereas returning strings of data, we would have some public static properties and we will actually return the identifier of that public static property. However, that is not the idea of this tutorial so I won't get into that now.
So the thing that is not practical with the above example is that the programmer should write a series of loops so as to describe every situation that may occur. The second thing that is not practical about it is its so-called impact on the semantics. Now what does that mean? It means that the public method register is not supposed to return the errors within itself. As a method, it is not his job to handle the errors but in this case to register the user.
So to the essence of this tutorial:
We throw an exception using the Throw block. It's literally nothing more than an ordinary class, the difference is that it is embedded in PHP and we do not need to write a file for it and so on. The first check does not pass because the string 'Keeper' has more than 4 characters. Upon executing this code we are returned with an error stating the following:
As I said in the introduction, the job of the Try segment (block) is to listen if anything between its scope throws and exception. If so, it sends it to the Catch block. Otherwise, if there is nothing wrong, no error is being returned as if the catch block does not exist.
The Catch block will be executed automatically only if any of these codes throw an exception. Catch accepts one parameter called $exc. It comes from exception and it's practically one regular object which has a few embedded methods for itself. They are:__toString();
- A magic method which represents an exception as a string value. It accepts no parameters therefore
getCode();
- Takes the exception code (the parameter for the code in the exception is obligatory). It accepts no parameters as well
getFile();
- Gets the file in which the exception has occurred
getLine();
- Gets the line in which the exception has occurred
getMessage();
- Grabs the exception message
getPrevious();
- Used to return the previous exception (if any) - not an obligatory parameter of the exception class
getTrace();
- Not sure really. Read it on php.net - I never came to use this one
getTraceAsString();
- Does the same as getTrace but converts the value to a stringNotice that Throw always works with objects which are exceptions. For example executing the class using getLine(); will output the line where the error has occurred. In this case it will be 13. If we use getFile(); it will respectively return the file where it has occurred and so on. I have explained them above.
In some specific cases, Try, Throw, Catch comes in handy mainly because of its flexibility. First, we listen for whatever exception there might occur, no matter where it has occurred.
As of our Catch block situations in our code, you need to be aware that their sequence of writing is important. So take that in mind as well.