Distinguish Frameworks

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Distinguish Frameworks

Post by josh »

Just a technicality, you should subclass classes of the framework, not modify its code
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Distinguish Frameworks

Post by Eran »

arborint wrote:Database calls you should be able to handle pretty well without @. Filesystem calls however are a completely different story. I don't think anyone can build a library with them in PHP without using @.
Can you give an example as to why this is the case? I have dealt extensively with files using PHP and never saw the need to use it. If an error occurs I would like to know about it
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Distinguish Frameworks

Post by alex.barylski »

Can you give an example as to why this is the case? I have dealt extensively with files using PHP and never saw the need to use it. If an error occurs I would like to know about it
Ditto (if I understand correctly). In Windows MFC for instance, CFile objects perform extensive error checking and throw exceptions when an error occurs -- makes for a more robust error checking system than programming procedurally. This is kind of the idea behind self testing objects so error surpression of any kind usually makes me cringe unless it's a quick fix for an eager client.

I somehow dought arborint meant that error surpression is a good or acceptable practice -- but I'd personally rather see an object perform extensive testing (above and beyond standard) and throw exceptions as required.
User avatar
php_east
Forum Contributor
Posts: 453
Joined: Sun Feb 22, 2009 1:31 pm
Location: Far Far East.

Re: Distinguish Frameworks

Post by php_east »

PCSpectra wrote:1+ for not using error surpression...I suppose there may be rare occassionas where it's justified and still not a design flaw -- but I cannot think of any off the top of my head.
i use this. would it be considered qualified ?

Code: Select all

$doc        = new DOMDocument();
@$doc->loadHTML($html);
 
just exactly what and where @ are or aren't qualified escapes me. my general rule is to suppress errors only when i want to insert my own error traps. but i don't know how others approach it.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Distinguish Frameworks

Post by Eran »

The only reason for this to throw an error is if the $html variable is empty or undefined. A simple check beforehand can catch that. Without actual data in the $html variable, creating a DOMDocument is moot anyway, so no reason to use error surpression.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Distinguish Frameworks

Post by alex.barylski »

First I would have to ask...what is causing the error?

I haven't used the DOMDocument in ages...a faultly non-validating XML file? In which case, why is the file faulty?
User avatar
php_east
Forum Contributor
Posts: 453
Joined: Sun Feb 22, 2009 1:31 pm
Location: Far Far East.

Re: Distinguish Frameworks

Post by php_east »

pytrin wrote:The only reason for this to throw an error is if the $html variable is empty or undefined. A simple check beforehand can catch that. Without actual data in the $html variable, creating a DOMDocument is moot anyway, so no reason to use error surpression.
no, it throws a warning for invalid HTML. and of course it is defined before i enter it. why would i want to create a DOM without having actual data ? :banghead:
PCSpectra wrote:First I would have to ask...what is causing the error?
I haven't used the DOMDocument in ages...a faultly non-validating XML file? In which case, why is the file faulty?
the erros are possibly caused by invalid/incompete html from outside. this isn't XML i am using, it's HTML. and the reason i use HTML is because it's not as strict as XML, domHTML specifically designed to be as such. However, invalid incoming $html ( a html from external source or file or whatever ) will make DOM issue warnings. this is irritating, the html DOM elements are there, but the warnings are of course for the invalid ones ( which are useless anyway ). hence my reason to suppress these warnings by @.

next i then proceed to process the html and its elements. i found this to be a very effective way to tame HTMLs. ( there some realy wierd HTML out there i tell you ).
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Distinguish Frameworks

Post by Eran »

no, it throws a warning for invalid HTML. and of course it is defined before i enter it. why would i want to create a DOM without having actual data ?
I'm not saying you would want to do that.. just pointing out a case where an error would be thrown that can't be caught using the libxml internal error mechanism. For malformed HTML/XML and such, you can simply use:

Code: Select all

$html = '<Asdcasd'; //Example of malformed HTML
libxml_use_internal_errors(true);
$doc        = new DOMDocument();
$doc->loadHTML($html);
$errors = libxml_get_errors();
You can then proceed to do whatever you'd like with those errors (including recovering from them), but if you suppress the errors, you don't know what went wrong.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Distinguish Frameworks

Post by alex.barylski »

will make DOM issue warnings. this is irritating, the html DOM elements are there, but the warnings are of course for the invalid ones ( which are useless anyway ). hence my reason to suppress these warnings by @.
The only time I have used SimpleXML or DocumentDOM was when I knew I would be manipulating valid documents (manifest files for CMS applications, etc). In which case I did nothing as I was gauranteed valid documents.

If I were using DOMDocument on user supplied HTML (ie: WYSIWYG, etc) I would probably run it through a library like HTML_Purifier first anyways, just to be safe.

I dunno, personally I would just rather solve the problem head on then use error surpression.
User avatar
php_east
Forum Contributor
Posts: 453
Joined: Sun Feb 22, 2009 1:31 pm
Location: Far Far East.

Re: Distinguish Frameworks

Post by php_east »

pytrin wrote:I'm not saying you would want to do that.. just pointing out a case where an error would be thrown that can't be caught using the libxml internal error mechanism.
ah, i see. ok.
pytrin wrote:For malformed HTML/XML and such, you can simply use:

Code: Select all

$html = '<Asdcasd'; //Example of malformed HTML
libxml_use_internal_errors(true);
$doc        = new DOMDocument();
$doc->loadHTML($html);
$errors = libxml_get_errors();
You can then proceed to do whatever you'd like with those errors (including recovering from them), but if you suppress the errors, you don't know what went wrong.
ah, perfectly valid. thanks.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Distinguish Frameworks

Post by Christopher »

I think we are back to the old discouraged versus forbidden discussion -- such as when discussing goto. Certainly suppressing messages is not generally a good practice -- especially by inexperienced programmers. But just as certainly you can think of @ has a fine grained version of error_reporting() and no one considers that function evil. I think we should be clear that it is suppressing messages to avoid proper implementation is the problem, not error suppression itself.
pytrin wrote:Can you give an example as to why this is the case? I have dealt extensively with files using PHP and never saw the need to use it.
That's a good question and I don't know if I have a good answer. I think it is more from looking through code in a lot of libraries and applications. Invariable I see that they suppress errors for functions like fopen(), fwrite(), dir(), glob(). I recall that the SQLite library is pretty finicky and reports even when you know good and well what you are doing. I think there are a mix of other system/PHP functions that report when you just don't want them to.
pytrin wrote:If an error occurs I would like to know about it
Well that is sort of the point of suppression. Many times you are using a function call to see if an "error" condition exists or not. I do recall having to do this when writing cache code. My recollection is that PHP was annoying when you were doing something intentionally in a library and did not want have the slew of messages that could not be worked around with out hacks.

Check out some frameworks or libraries -- maybe this is not still the case and I am thinking of older versions of PHP ...
(#10850)
User avatar
php_east
Forum Contributor
Posts: 453
Joined: Sun Feb 22, 2009 1:31 pm
Location: Far Far East.

Re: Distinguish Frameworks

Post by php_east »

PCSpectra wrote:The only time I have used SimpleXML or DocumentDOM was when I knew I would be manipulating valid documents (manifest files for CMS applications, etc). In which case I did nothing as I was gauranteed valid documents.
okay, but i don't have that privilege.
PCSpectra wrote:If I were using DOMDocument on user supplied HTML (ie: WYSIWYG, etc) I would probably run it through a library like HTML_Purifier first anyways, just to be safe. I dunno, personally I would just rather solve the problem head on then use error surpression.
i would have to rethink my approach. your point is valid. thanks.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Distinguish Frameworks

Post by alex.barylski »

I think we are back to the old discouraged versus forbidden discussion -- such as when discussing goto. Certainly suppressing messages is not generally a good practice -- especially by inexperienced programmers. But just as certainly you can think of @ has a fine grained version of error_reporting() and no one considers that function evil. I think we should be clear that it is suppressing messages to avoid proper implementation is the problem, not error suppression itself.
Agreed.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Distinguish Frameworks

Post by Eran »

I agree too with Chris' sentiments. Personally, if I were releasing a library or package of some sort, it would not have any error suppression as I would like to know about all the errors that it can produce. Knowing that something can produce an error and choosing to ignore it is bad practice - as we all agree.

As a side note I always develop and deploy on E_STRICT. The only thing I change is the display_errors directive.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Distinguish Frameworks

Post by VladSun »

There are 10 types of people in this world, those who understand binary and those who don't
Post Reply