Re: patch files for PEAR

As far as the @ feature goes it has been rather abused within PEAR. There are some instances, however, where it might be valuable, e.g. when including a file if you do something like... if (!@include('filename.php')) {

    print "Unable to load filename.php";

} It suppresses php's own errors (Cleaner output essentially). I have also used it when running $browser = get_browser() so that people without browscap wouldn't experience problems because it was an optional item. The problem comes in when you have packages like Auth (no offense to the authors) which use an @ before a session function, and there's no further error reporting. Another word's sessions cannot be working (for an authentication package whose sole purpose is such) and the user can never know about it. Anyhow, I'll agree it is overused, and I think some pear developers need to reexamine where they use it in their code. Also, if you're using it, are you throwing another error so that a user knows something is wrong??? - Stan Tomas V.V.Cox wrote:

On Monday, August 25, 2003 7:50, Brad Bulger wrote:

a few patch files based on trying to run with the Web frontend. some undefined variables, some errors that needed more info. if you like them, they're yours.

a general comment: a while ago, someone proposed to internals a php.ini setting for disabling the '@' error-suppression mechanism. he basically got hooted out of school, but i am beginning to see what he meant.

the @ thing is at least close to being overused. it's become like duct tape. in trying to make things work with PHP 5, whenever there was a problem, i would frequently have to remove layer after layer of error suppression until i found out what wasn't working. or using it to avoid undefined index errors. i mean, that works, but hmm.

I'm completely against using the '@' feature, as the error it produces does not be shown but will be still logged if you use log_errors. Please guys avoid it use. That "lazy" feature only hides potential bugs.