Page 3 of 4

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 7:05 pm
by josh
Just a technicality, you should subclass classes of the framework, not modify its code

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 8:26 pm
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

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 8:33 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 8:39 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 8:52 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 8:55 pm
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?

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:09 pm
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 ).

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:17 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:42 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:50 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:51 pm
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 ...

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:55 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 9:58 pm
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.

Re: Distinguish Frameworks

Posted: Tue Apr 14, 2009 10:04 pm
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.

Re: Distinguish Frameworks

Posted: Wed Apr 15, 2009 1:39 am
by VladSun