So, I have a form om my webpage which insert into a database. It throws a die(mysql_error()) into a blank page if not all fields have a value. I want this error message pasted over my form, but not loose the values already inputed. I have thought about both reloading the page with a page.php?error=... and making code to check if all fields have value (which will be long and feels unnecessary since what I want is already on my screen.
Do you think something like if(field1 has no value | field2 has no value | ....){ don't do anything and do rest is the best and most effectiv?
But if I want show which field is missing aswell, it will be a LOT of code...
You don't really want to output the exact die() error message, as the user won't be able to understand it, and chances if they would understand it, they're potentially the kind of users you don't want being able to see it!
Not really sure of your situation (as you didn't post any code) but from what you've said I'd suggest using try & catch, and handling any errors that occur, for example:
try {
// perform your database query
} catch (SQLException $error_msg) { // catch the error if goes wrong
//$error_msg contains the information from the error
return 'We`re sorry, your form submission could not be handled at this time.';
}
// if we got to this stage, there were no problems
return 'success';
That way, you can verify the reasons why the Exception occured, catching the real error message so they don't see it, then returning some other output back to the user in a format that they can understand.
in all of your input fields set the html value attribute to value = <?php echo #$_POST['fieldname'] ?>
also, instead of using die, use $error = mysql_error(); and then echo $error later on
Related
Here is some sample code:
try
{
$db->query($sql_q1);
$db->query($sql_q2);
$db->query($sql_q3);
}
catch (Exception $e)
{
echo $e->getMessage();
}
How can I see which query caused the error in catch so I can see it along with the error message? And a line number won't work do me, because my queries are often dynamically built.
Well, first of all, just like Usman Munir said, if you won't catch it, there will be more information than if you catch. Just try to remove that try..catch stuff from your code and you will see the first 15 characters of the query.
But in case you need the entire query, there is a way, though not that it will give it to you right away, like a designated variable that contains specifically "last executed query", but well technically you can
There is a thing called a stack trace, intended for the exact purpose. It can show you all the calls made in your code that led to the error, including all function parameters.
Change your code to this
try
{
$db->query($sql_q1);
$db->query($sql_q2);
$db->query($sql_q3);
}
catch (Exception $e)
{
var_dump($e->getTrace());
// or to get the full error info, just
var_dump($e);
}
and you will see your query in the full glory, though it will be quite a pain to get the actual query automatically if that's your goal. but if you want to just log/visually inspect the error information, it will do.
Not that obviously you should never put var_dump() inside try_catch() in any real life code. Instead, some handling code must be put into your error handler. Especially if your purpose is debugging. Hence, your real life code should be rather this
// somewhere in the bootstrap
include 'error_handler.php';
// anywhere in your code
$db->query($sql_q1);
$db->query($sql_q2);
$db->query($sql_q3);
and in the error_handler.php you can add a code to print the full stack trace. an example for such a file you can find in the article Usman Munir posted a link to (which incidentally I wrote).
Note that stack traces tend to grow really big, and can litter your logs significantly. So consider making extended output optional.
One possible solution if you are trying to know the previously executed query would be to store your SQL in a single variable and change it for each statement. Then if an error occurs with a query you can just echo out the contents of the variable. Unless there is a specific reason you need to have multiple variables to hold your queries.
I have a single entry into my site: http://mysite.com/index.php?this=that&andthis=that. I use it for all tasks such as originally displaying a page, submitting a form, and ajax calls. I then route it to the appropriate task.
Are there any reason why it is preferred to have another entry into the the site for ajax calls such as http://mysite.com/ajax.php instead of index.php?
As I know in my modest experience, there is no technical reason for separating the both behaviors.
But you might need to have some specific treatment, like when you have an ajax request you need to handle errors and display them to the user differently.
e.g: for exceptions, you may need to enclose your code in a try catch, and return the error message in a json format:
try{
// your AJAX request code here
} catch (Exception $e){
// threat error here
$msgErr = $e->getMessage();
echo json_encode( array( "success"=>"failure", "msg" => $msgErr ) );
}
and you show the message to the end user in an alert message box, so once you have such needs it more logic to make a separate entry point for ajax request in order to automate your behavior instead of making again every time.
I hope I've made my tought clear enough, if not I would be happy to try again.
I hope it helps.
This might be a n00bish question, but whatever. Is okay to use exceptions for form validation? Let's say I have a form which asks users for their name and email, is right to do the following?
try {
if (empty($_POST["name"])) {
throw new UserRegistrationException("Your name cannot be empty.");
}
if (filter_var($_POST["email"])) {
throw new UserRegistrationException("Invalid email");
}
// Save new user into database
} catch (UserRegistrationException $e) {
// Show errors on screen
}
Also -if this is in fact the correct way to do it- if the user submits both an empty name and an invalid email, would both of the exceptions execute or only the one that appears first (the name one in this case)?
I'm using PHP by the way.
I personally like to use exceptions for anything that should stop or alter program flow. In other words, if validation of a particular field changes how data is processed, or requires the process to be repeated, then I always use exception for error handling.
If it's trivial, or I'm simply compiling a list of error messages, then I do not trigger exceptions.
To answer questions, two exceptions cannot be thrown at the same time. The first throw statement that is reached will be thrown. That's not to say that sometimes it doesn't make sense to rethrow as another type of exception.
The use case for exceptions is for exceptional conditions. In this case, do you expect the username and password fields to be blank? If you're displaying a web form, I'd argue that, yes, you do expect blank username and password fields, and so you should be checking for that condition explicitly, rather than throwing an exception.
To answer your specific question, both exceptions will not be thrown if an error is encountered. The throw statement will send the program into the catch block. From there control will flow as normal.
Why not using array of errors instead of throwing errors and check if it's not empty later in the code.... Exception handling is very confusing to me , I can not understand it's purpose ... can anybody enlighten me !?
they compare it with die() as better not to stop the execution of the code , why would I stop the execution of code if I don't want to !? ofcourse I do
I'm a beginner programmer , it might be confusing to you as well , or because i'm not very experienced in this ugly thing.
Please in the context of PHP only.
One reason you might decide to throw an exception is because you can add a jump in control flow without an explicit piece of syntax. What do I mean by that?
rather than
$returnVal = doSomeDiskFunction();
if($returnVal == $ERROR_CODEA)
{
// do some stuff
}
else if( $returnVal == $ERROR_CODEB)
{
//do some stuff
}
$returnVal = doSomeOtherDiskFunction();
if($returnVal == $ERROR_CODEA)
{
// do some stuff
}
else if( $returnVal == $ERROR_CODEB)
{
//do some stuff
}
you could just have
try{
doSomeDiskFunction();
doSomeOtherDiskFunction();
}
catch(ExceptionTyepA $exceptionA)
{
//do some stuff
}
catch(ExceptionTypeB $exceptionB)
{
//do some stuff
}
Seems a lot cleaner, yes??? It's also a formal way of alerting calling code that it needs to deal with potential error conditions if you choose to have the exception propogate upwards in the call stack.
Also, exceptions should be used for code that you don't expect to happen, like failing to connect to a database, not code that you DO expect to happen, like a user submitting bad data. The other poster made the point that you kind of expect a user to make a lot of errors filling out a form, so you wouldn't throw an exception when you come across some data that is in a bad user-entered format, because you expect user data to be poor quality.
It really depends what type of error you're talking about.
I always die(); for really bad errors, like if the application couldn't connect to the database.
But for anything that takes user input, like a form, it's better to use arrays of errors that the user can see all at once, instead of correcting one field at a time and repeatedly having to press submit.
(If you want to know in more detail, I often use an array of arrays to display errors, since one field could potentially have multiple things wrong with it. For example, if a user tries to register an account with username "1337", I will use a validator to check against multiple conditions and it will return an array with things like "username must be at least 5 characters long", "username must contain at least three letters", "that username has been disallowed by the administrator" and all those messages will be displayed simultaneously above that particular field)
There is a way to code completely without exception handling. For example, if you have a method that returns the length of an object, have it return -1 if there's been an error. This is how most C API's are built.
That said, when you're building complex systems, and you have a ton of "black box" code that might behave wrongly, exceptions help. The way exceptions work is like this: when someone "throws", folks on the call stack start getting notified. One step at a time. One of these methods can "Catch" the exception and handle it.
Why is this useful: you can have a DB layer that has lots of logic inside that throws exceptions. If something goes wrong there, your DB exception handling code can fail gracefully, showing a nice error message to the user; it can also send a text message to the admin, demanding attention.
You can even create a hierarchy of exception handlers: you can re-throw the exception after you've done something with it.
PHP's exceptions sucks hard, but they still have their basics benefits:
Exception provides much more information about "What went wrong?" in much better form (exception is an object)
They make your code clearer
They are the only reasonable way to break execution of the part of code (that doesn't work as it supposes to), fix (if possible) what need to be fixed and continue without complete failure.
Really it depends on the language. C is similar in that respect -- it doesn't force you to handle an error. Most functions return -1 if they had a problem; it's up to you to check 'errno' to see what happened.
Exceptions are generally a good thing though. You rarely want to blindly continue running if an error occurred (Never never NEVER say "On Error Resume Next" in Visual Basic. Please.). It's quite easy to catch the exception and do nothing if you are sure you don't need to do anything.
I'm trying to build a registration system using PHP and the AJAX components of jquery.
My jQuery takes the values of the username and password fields and makes a POST request to the PHP script, which grabs the values using $_POST and saves them to the database.
Of course, i'm wanting to make sure that there aren't any duplicate usernames, and beyond using the PHP mysql_error() function, i wasn't sure how to do this.
So i want to set my PHP to first check for entries in the database with the username the person enters in the form, if it exists, i'd like to return a custom error message to the user using the php return() feature.
How can i use jQuery to first POST the values to the script, and then return any data/ custom error messages that i am creating with return();
By the way, security is not an issue here.
Simplest way would be to make a page, for example, post.php. post.php will do all the checking and stuff you want and, I know you want to use return, but just echoing the stuff back would be the absolute easiest. So, echo any error or even a value (for example, you can echo back -1 for a false or a 1 for a true).
The jQuery side is pretty simple:
$('form').submit(function(){
$.post('post.php',{username:$('#username').val(),password:$('#password').val()},function(data){
//username and password == $_POST['username'] && $_POST['password']
//data will now equal anything you echo back. So, lets say you did as my example and used -1 for an error
if(data==-1){alert('ERROR');}
});
return false;
});
If there is an error you will get an alert otherwise nothing will happen at all. Now you could do an else{} and have whatever you want for if there is no error.