Also, in regards to forms, i send a form token with all forms to valid the forms, and if the form token is not present in the handling of the form, or the token is wrong, then it produces an error. What kind of error would this be, an error, an exception, a user input?
I would to say: exception, that catched with specific error site(500). Actually CSRF token could be correct but just too old (expired).
Iām, still having trouble understanding why using a try/catch is better in some cases than to use trigger_error(). I dont understand what the benefit of using one over the other is, and i dont understand what the benefit is of ācatchingā an error.
Itās not ābetterā. Itās diferently. As I said, if you use exception, you have a potential ability to catch it and continue code execution with some way. By trigger error you have just one way - to show tracing.
If i use try/catch i can try a code, and if it fails, then i can use catch to do something else, but can i have that same functionality with trigger_error()?
trigger_error() just triggers a new error, but it can continue with the script no? I could just trigger an error if something fails.
I guess the difference is with a try/catch you are checking to see if something fails, and with trigger_error() something already failed and you are setting an error?
I donāt know when to use which
f i use try/catch i can try a code, and if it fails, then i can use catch to do something else, but can i have that same functionality with
trigger_error()?
trigger_error()just triggers a new error, but it can continue with the script no? I could just trigger an error if something fails.
That is not the best way, I think. Error handling has ist own mission - to handle errors. Thatās all.
I guess the difference is with a try/catch you are checking to see if something fails, and with
trigger_error()something already failed and you are setting an error?
No. If error already failed, will be authomatically executed function, that set by set_error_handler(). trigger_error() init this handler without error.
ok, so theoretically, i would need to just set up the error handler class, and i wouldnāt need to set any errors or do anything with the error handler because it will all be automatic, and if so, when would i even use trigger_error()?
And then i would use exceptions for something separate of the error handling?
You can use trigger_error(), if you 100% sure, that is exactly error and no execution more.
Hmā¦ For 15 years as PHP developer, I just canāt remember trigger_error() using in my code. But clear theoretically itās possible.
Well if you went 15 years without it i guess it may not be very necessary 
From what i just read it seems trigger_error() is mainly useful for development.
So for errors i just need to set up the error handler, and i can basically leave it (unless there is an error with the handler it self of course) and php will use it and set errors it self right?
Yes.
Good, so i understood something!
Now about the exceptions, iām still not sure about when i should use exceptions.
I understand that they are different from actual errors, like the ones php sends, but i donāt understand quite yet when something is an exception, and when something is a āuser input errorā.
For example, i have a sign up form that requires an email address, there are a few steps to validate the email that the user entered, but iām not sure which is a user input error and which is an exception:
Another example:
A user who is logged in to the system, goes to the signup page, this page is only accessible by users who are not logged in. Is this an exception?
1, 2, 3 - input error.
4 - donāt understand. Why not allowed?
5 - If you mean something like āconnection failedā - exception 500.
A user who is logged in to the system, goes to the signup page, this page is only accessible by users who are not logged in. Is this an exception?
Exception 403.
If someone tried to register with an email of admin@website.com or tries to use an email that is in an array of not allowed emails.
I have an array of email addresses that shouldnāt be used, and if someone tries to register with one of these email address, it should not work.
Now that i write this, it seems like this is an input error, right?
you mean its an exception and they should be sent to a 403 page?
Now that i write this, it seems like this is an input error, right?
Hmā¦ If you mean just service addresses, then you right - input error. But if you mean black list - I would to say - exception 403.
you mean its an exception and they should be sent to a 403 page?
Yes.
I would actually this is an input error and a message should be shown to the user so that they know what went wrong and how they can fix it, e.g., āyou are not allowed to use this email addressā or something like that.
Regarding the different kinds of exceptions you could use separate classes for the different HTTP status codes, e.g. an NotFoundException for 404, AccessNotAllowed for 403, anything else for 500.
And then in the error handler check for those exceptions specifically and act accordingly.
Just make sure you only throw these exceptions from controllers; any other classes (e.g. repositories and such) are not supposed to know about HTTP.
Maybe iām misunderstanding, but what do you mean by error handler here?
From what i understood from everything in this topic is that there should be 1 class for handling errors, and another for handling exceptions.
Are you referring to an exception handler?
This is where my thought and understanding is at the moment:
Error handling:
I will create an ErrorHandler() class, this class will handle the errors, log them, send an email to the development team, and also save the errors in the database for future reference/fixing the error.
I will use the set_error_handler() function to set the ErrorHandler() as the apps error handler, and for this part of the subject i am done, since any error from now on will trigger this handler, it will log, email, and save the error to the database all on its own, so i should not have to touch this error handler or do anything with errors besides prevent them and fix them.
These errors would result in a 500 error page.
Is that correct?
Exception handling:
There are some exceptions that i would want to track, by track i mean to save them to the database to work on/fix/prevent in the future. So i will create an ExceptionHandler() class that will handle the exceptions, and use set_exception_handler() for this. This class will take a similar approach as the ErrorHandler() took but only for certain exceptions. For those that require it, the class will send an email to dev team, and save the exception to the database.
This would usually occure when there is an exception that is āfatalā or that shouldnt have happened, and in addition to tracking it, the user will be sent to a 403 page.
Correct?
User inputs:
When a user fills out a form and the input is not valid, i will use my existing form handler to save these invalid inputs with a message to show the user.
Any user input errors will be handled by this class.
Right?
Alerts class:
Since users could get alerts from exceptions and input errors, i need a way to show them alerts for these things. So i will create an Alerts() class that will get the alerts from the FormHandler() an from the ExceptionHandler(), and it will display these alerts to the users.
I will save the user input alerts in a session variable in the actual formHandler() class, same for the ExceptionHandler() class, and the Alerts() class will check these session variables to see if there are any alerts in them, if there are then display them, if not then dont.
Sounds correct?
Thatās basically what i understand i should do at this point, am i wrong about them?
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.