Jump to content

Scope of calling exit


Go to solution Solved by ginerjm,

Recommended Posts

Hi

 

If I have two php files, and one calls a function in another, if I want to return a response and then call exit; to make sure nothing else runs (part of error handling is to send a response and then force exit), do I call exit in the function or in the script after calling the function?

 

Or does it really not make any difference?

 

e.g.

<?php

include_once('otherfile.php');

functionName();
// call exit; here?

?>

otherfile.php

<?php

public function functionName()
{
   echo "Error: function error";
   // or if I call exit; here?
}

?>
Link to comment
https://forums.phpfreaks.com/topic/306435-scope-of-calling-exit/
Share on other sites

You would call return to return from a function and call exit from the main line code that has called that function. With a return you can send back any kind of result that you wish so that the caller is informed properly. Exit is simply a departure from PHP.

You would call return to return from a function and call exit from the main line code that has called that function. With a return you can send back any kind of result that you wish so that the caller is informed properly. Exit is simply a departure from PHP.

 

So to give you a bit more explanation, the functionName function is like an error handler, so this will be called multiple times from the main file, so I was wanting to put the exit; call inside of the functionName function so I didn't have to keep calling exit after I have called functionName all the time.

 

e.g.

if()
{

}
else
{
   functionName();
   exit;
}
Edited by mds1256

It is your decision but proper programming practice would dictate that if a mainline piece of code is calling a function then that caller will expect a return. To call a function that never returns is a maintenance-programmer's worst nightmare. If you have need to write a function to do something out-of-line then you should handle the exit from that point, not in another block of code.

 

Really? You want to write poor code to save typing 7 chars on your keyboard?

It is your decision but proper programming practice would dictate that if a mainline piece of code is calling a function then that caller will expect a return. To call a function that never returns is a maintenance-programmer's worst nightmare. If you have need to write a function to do something out-of-line then you should handle the exit from that point, not in another block of code.

 

Really? You want to write poor code to save typing 7 chars on your keyboard?

It will be called multiple times within the main document, so it was just to tidy it up (call it in the functionName once rather than multiple times). Not wanting to write poor code, hence this post, just wanted to know the proper way or doing this and if that means that I have to call exit after each function call then that is fine. Was just trying to make the code as readable as possible.

  • Solution

Placing the exit() call following the function DOES make it as "readable as possible". Imagine you are looking at someone else's code where you see a call to a function and nothing after it and you wonder where the code is supposed to go next....

Placing the exit() call following the function DOES make it as "readable as possible". Imagine you are looking at someone else's code where you see a call to a function and nothing after it and you wonder where the code is supposed to go next....

To be fair when you say it like that you’re right.

 

Thanks for this

Edited by mds1256

Also, I would suggest reconfiguring the logic for the function and the code that calls the function. This would be easieer to write/maintain

 

 

public function checkName()
{
    //Simply return the test condition (will return Boolean TRUE/FALE
    return (foo == bar);    
}
 

Then in the code that call the function, configure it like this:

if(!checkName)
{
    //Ouput error condition (and exit?)
}
 
//Continue success condition - no need for an else
 

However, I would also state that exit() is a poor way to handle error conditions. It almost always results in improperly formatted HTML pages. It doesn't take much to create an alternative path to produce a valid page with appropriate error conditions.

Edited by requinix
fixing bbcode

Also, I would suggest reconfiguring the logic for the function and the code that calls the function. This would be easieer to write/maintain

 

public function checkName()
{
    //Simply return the test condition (will return Boolean TRUE/FALE
    return (foo == bar);    
}
Then in the code that call the function, configure it like this:

if(!checkName)
{
    //Ouput error condition (and exit?)
}
 
//Continue success condition - no need for an else
However, I would also state that exit() is a poor way to handle error conditions. It almost always results in improperly formatted HTML pages. It doesn't take much to create an alternative path to produce a valid page with appropriate error conditions.

Thanks, it’s a JSON response I am echoing out so using exit should be fine?

 

Yeah your above example is spot on to what I am trying to do.

Thanks, it’s a JSON response I am echoing out so using exit should be fine?

 

Possibly. exit() is typically overused for the wrong scenarios, but it does have its place. As long as your exit(s) ensure there will be no adverse effects, this may be one of those scenarios.

  • Like 1
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.