Distinguish Frameworks
Moderator: General Moderators
Re: Distinguish Frameworks
Just a technicality, you should subclass classes of the framework, not modify its code
Re: Distinguish Frameworks
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 itarborint 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 @.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Distinguish Frameworks
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.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
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.
Re: Distinguish Frameworks
i use this. would it be considered qualified ?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.
Code: Select all
$doc = new DOMDocument();
@$doc->loadHTML($html);
Re: Distinguish Frameworks
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
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?
I haven't used the DOMDocument in ages...a faultly non-validating XML file? In which case, why is the file faulty?
Re: Distinguish Frameworks
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 ?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.
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 @.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?
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 ).
Re: Distinguish Frameworks
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: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 ?
Code: Select all
$html = '<Asdcasd'; //Example of malformed HTML
libxml_use_internal_errors(true);
$doc = new DOMDocument();
$doc->loadHTML($html);
$errors = libxml_get_errors();-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Distinguish Frameworks
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.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 @.
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.
Re: Distinguish Frameworks
ah, i see. ok.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, perfectly valid. thanks.pytrin wrote:For malformed HTML/XML and such, you can simply use: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.Code: Select all
$html = '<Asdcasd'; //Example of malformed HTML libxml_use_internal_errors(true); $doc = new DOMDocument(); $doc->loadHTML($html); $errors = libxml_get_errors();
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Distinguish Frameworks
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.
Check out some frameworks or libraries -- maybe this is not still the case and I am thinking of older versions of PHP ...
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: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.
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.pytrin wrote:If an error occurs I would like to know about it
Check out some frameworks or libraries -- maybe this is not still the case and I am thinking of older versions of PHP ...
(#10850)
Re: Distinguish Frameworks
okay, but i don't have that privilege.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.
i would have to rethink my approach. your point is valid. thanks.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.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Distinguish Frameworks
Agreed.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.
Re: Distinguish Frameworks
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.
As a side note I always develop and deploy on E_STRICT. The only thing I change is the display_errors directive.
Re: Distinguish Frameworks
There are 10 types of people in this world, those who understand binary and those who don't