Re: [php-49] Is it bad practice to die 'inside' a class?

From: Ian M.
Sent on: Tuesday, September 15, 2009 2:27 PM
You could define a new exception class (let's call it RedirectException... which extends class Exception) whose purpose is to portray an error which can only be resolved by redirecting to another page.�� When throwing the error, you could write in a URL and have a universal catcher in a global_prepend script that handled this type of exception.�� This gives you a clean exit and single point of action which can be easily located and monitored.

Now that we're getting all OOPy, you can consider things such as catching the RedirectException halfway up the chain and modifying the URL if needed.

As others have mentioned, calling die() or exit won't cause any leaking of system resources unless your version of PHP or one of its extensions has a specific bug.�� In my experience, modern versions of PHP are virtually leak-free and a single process is stable enough to be run as a daemon for days or even months at a time.

--Ian


On Tue, Sep 15, 2009 at 1:03 PM, Garth Henson <[address removed]> wrote:
Darcy, I don't believe you could pass the actual URL unless you got into parsing out the description of the custom error (which in and of itself sort of defeats the purpose of errors), but you could easily have a redirect exception class in which all error codes are distinctly defined with the location of the page to which you need to redirect. This way, when you come upon a redirect exception in your code, whether implicitly or explicitly, you will know to where the page should redirect.

Hope this makes some sense. Trying to write quick responses between calls today ;-)


Garth Henson
Guahan Web
Email: [address removed]
Web: http://www.guahanweb.com
Chat Google Talk: henson.garth Skype: guahan.web
Contact Me LinkedinFacebookTwitter




On Tue, Sep 15, 2009 at 3:54 PM, darcy w. christ <[address removed]> wrote:
garth, i'm interested in what you are suggesting. ��how would you pass a url as part of an exception and make sure that it is caught and redirected?



On Sep 15, 2009, at 12:46 PM, Garth Henson wrote:

Let me clarify, because indeed, there are cases where redirection or ceasing of execution may be entirely valid within a method or function call, but as a rule, I firmly believe that this should only be done within methods designed for that specific purpose (and WELL documented at that). Typically, this type of action would be part of a static method within some sort of management object - whether session management or whatever.

To do what you are after, it seems that it would be much more appropriate to extend the Exception class (assuming you are in PHP5 or higher) and write up some custom error codes and handling techniques to do what you are after. That way, they can still be entirely reused without having to completely break up the ideals of the OOP classes you are developing.

Garth Henson
Guahan Web
Email: [address removed]
Web: http://www.guahanweb.com
Chat Google Talk: henson.garth Skype: guahan.web
Contact Me LinkedinFacebookTwitter




On Tue, Sep 15, 2009 at 3:38 PM, darcy w. christ <[address removed]> wrote:
i understand garth's point, but in some circumstances, i don't think there is any issue with ending code execution wherever you want, including within a class. ��i often employ a redirect for 'correcting' the URL. ��this could be called almost anywhere in my code, including within classes. ��as i understand, PHP has no problem with garbage collection in these cases. ��the only thing i make sure i do is register a function using register_shutdown_function(). ��this allows me to write logs and other fun things before completing my academic harakiri (i know - bad play on words!).




On Sep 15, 2009, at 12:28 PM, Garth Henson wrote:

I would submit that it is indeed a bad practice for a process to end without returning from within a class or structure like this. It would be different if there were a visitor method being used that actually did the redirect from the result of the class' method call, but to hard code a redirect like this and die within can cause for a massive amount of headache when trying to manage your code base down the road.

I'm not familiar enough with the garbage collection of PHP to answer for the raw memory consumption of following such a practice, but I can definitely answer from the practical coding side.

Hope this helps some.

Garth Henson
Guahan Web
Email: [address removed]
Web: http://www.guahanweb.com
Chat Google Talk: henson.garth Skype: guahan.web
Contact Me LinkedinFacebookTwitter





On Tue, Sep 15, 2009 at 3:23 PM, David Malouf <[address removed]> wrote:
Not sure if I can word this well, so please ask for clarification as needed...

Hypothetical example of the concept (that is, I'm not looking for a better way to do this particular task, just using it as a simplified example):

MainPage.php
���� <? php
���� include ('theClass.php');
���� $newUser = new theClass();
���� $newUser->checkIP;
���� echo "Welcome...";
���� ...
���� ?>

theClass.php
���� ...������������������������������������ // setup-stuff
���� function chekIP() {
�������������� if ($_SERVER['REMOTE_ADDR'] != '[masked]') {
������������������������������ include ('aDifferentLoginPage.php');���������������������� //�� THIS LINE!!
�� �� �� �� �� �� �� �� die();
�������������� }
������ }


Roughly, if the user is not at[masked], then they are bounced out to a different page BY THE CLASS!!

1) Is this a bad idea or is it okay practice?
2) does this lead to memory-leak or other wasted RAM/processing issues?


David





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by David Malouf ([address removed]) from The Seattle PHP Meetup Group.
To learn more about David Malouf, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Garth Henson ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Garth Henson, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA


~/darcy w. christ
1000camels






--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by darcy w. christ ([address removed]) from The Seattle PHP Meetup Group.
To learn more about darcy w. christ, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Garth Henson ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Garth Henson, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA


~/darcy w. christ
1000camels






--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by darcy w. christ ([address removed]) from The Seattle PHP Meetup Group.
To learn more about darcy w. christ, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Garth Henson ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Garth Henson, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy