Using extensively the php function Exit();

[leZourite]

Hi here !

I have been using a LOT (and when i mean a lot.. it is !) the function Exit(); when dealing with my code, and i was wondering if it's a good practice, example :

instead of doing this :

Code: [Select]

if (some condition) {

///execute some code
}
else {

// or else execute this other code

} //no more processing from here

I do this (though not systematically) :

 

Code: [Select]

if (some condition NOT MET) {

exit ('Some reasons WHY');

}

// Continue processing...

In both case if the condition are met or not, some things are done, or not. But i find the later more straightforward if the condition is not met (and i don't want to continue processing of course) i will rather stop there, on the other hand if the condition are met, it will bypass the exit, and then continue processing.

of course i don't use that if i need to attribute different value to a variable for example :

 

Code: [Select]


if (some validated variable == "some value") {

$somevariable = "somevalue";
}
else {

$somevariable = "someOthervalue";

}

// Continue processing depending of the value in $somevariable

i tend to think my way of dealing with things tend to get less code to manage and is much more faster to process, but of course i am not 100% sure about that. Any input will be greatly appreciated

[Zeggy]

You could also use break or continue.

[leZourite]

That's not really the point break only exits out of loops, it doesn't stop the php from continue to do processing. And continue... well allows a loop to continue after a break.

I am debating if using "Exit" as just killing the process of the (whole) page at the exit point is a good practice instead of doing a long suite of if elseif elses...

Actually i didn't find any problem with it on the performance side, but i found something better : using return; by using return instead of exit, i stop the current include for being parsed, but resume from the main script

[Zeggy]

Oh, okay, sorry, I didn't read everything

Normally I would use if and else, I don't really use exit much. If you have a footer include for stuff to be done at the end of the document, you need to add that just before every time you call exit.
But that's the way I code, maybe you don't have processing done in the footer

[leZourite]

i didn't at first... and because of the "cache" nature  this sort of template even if the footer disappear the main layout doesn't get destroyed (which is great). But i think i am gonna use return; it does the same job more or less but contained to the current include

so if i have a structure like
<?php

include 'header.php';
include 'main.php';
include 'footer.php';

?>

and in the main.php i have other includes, if i return; at one point only the inserted includes will stop to parse.

[JGadrow]

Correct me if I'm wrong, but it appears you're using 'exit' in case an error is encountered correct?

If you're using PHP5 you could use Exceptions instead. The fun part about exceptions is that you can encapsulate all your error handling in one place. Such as:

Code: [Select]

try
{
if (!$someCondition)
throw new Exception ('Condition failed ... ');

if (!$someOtherCondition)
throw new Exception ('Some Other Condition failed ...');
}
catch (Exception $e)
{
echo $e->GetMessage ();
exit ();
}


[leZourite]

nope it's not for error detection (exit won't prevent the error, and if it appears before the exit statement it will just stop the loading past the error.

Nope actually i use it as a mechanism to prevent further loading of the page and directly give a message to the user...

Let's say : i setup a website with some inputs, and the user is trying to hack (like modifying informations from the post on the fly, or changing the value expected etc) the exit works in this case (and only this case) as a redirect : IE you tried to do something wrong so the processing is halted.

but using the combination of echo and return gives me the same things without interrupting the flow of the webpage so i use it much more eagerly now

[JGadrow]

A hacker tries to exploit loopholes / bugs (which I lump in with 'errors') and that's what I had guessed it was for.

Exceptions > Exit () because your page also continues to process!

Say you're inserting 3 rows into a database in a script that registers new users.
A script kiddie comes along and specifies username 'foobar' password 'bad, evil SQL injection'
Your script is inserting usernames and passwords in separate locations (for the sake of this example, not recommended lol)
So, processing on the 'username' component completes without a problem.
However, your script detects that the user is hacking on 'password' and exits.

This leaves the username input in the database.

Obviously, this isn't a 'real-life' example, but with exceptions you could catch the error at a specified 'error handling' portion of your script and roll-back your application to its previous state, thus eliminating the unnecessary username.

As a general rule, I never use exit (or die) unless I'm performing a sanity check.

*As a note on the example above, you should using prepared statements to avoid having to sanitize user input if your database supports them. Prepared statements with bound parameters are considered the strongest form of protection against SQL injection attacks at the current time. However, it costs an extra communication with the database server so be careful how you utilize them

[leZourite]

well of course i do sanity checks all the time (i have build up a small library of functions for that ) !

So exit is used pretty much all the time, i do lots of checks BEFORE doing any processing so processing interruption occurs well before any hacking attempts can succeed (i am speaking of sql/xss injection mostly), session fixation is dealt differently