how to successfully turn off error reporting to avoid annoyig undefined index errors

[marcnyc]

I wouldn't think so, but I am not an expert

[marcnyc]

any other ideas? I am a little bit at a loss here with this

[MarkR]

By and large, you should write code which doesn't generate notices at all during normal operation.

Usually the way of doing this is by judicious use of (e.g.) isset(), but also occasional careful use of "@" operator (Beware: never call functions with @).

Having error_reporting set to 0 (which is what @ does temporarily) is very dangerous and annoying, because it disables all error reporting, including fatals.

Therefore if a fatal occurs, the script terminates unceremoniously with no error, and there's no easy way of finding out what the problem was.

In my opinion, PHP should not allow you to mask fatals; it is of absolutely no practical value.

Specifically, either a function or method call generates a fatal if that function / method is not defined - but this happens at runtime not compile time, so it will only occur if that code is actually hit.

I normally run all my applications with an error handler which terminates the script and logs the error, for all non-masked errors including E_NOTICE. This helps to detect errors early and prevent PHP from "charging headlong into oblivion" under unexpected conditions, e.g. if an expected POST parameter is missing, it will fail the script rather than proceeding with an undefined value.

Mark

[marcnyc]

I agree of course.
I know I should have coded better, but this was years ago and you learn a lot during years...
Now my priority is getting the code to produce error-free pages for end-users. I will then later on address all these issues.
I just want to turn off error handling for notices right now.

[bradgrafelman]

Use [man]ini_set[/man] to turn off display_errors?

At any rate, I would say stop fighting error reporting and fix the errors 😉

[MarkR]

You can't mask your "unimportant" notices while keeping the "important" ones. I recommend that unless your application is of mammoth size, you simply do a reasonable QA exercise, going through suppressing the unwanted notices on a case-by-case basis.

You should be able to do this on your dev server easily if you install an error handler which shouts and screams blue murder on every notice, dumping the stack trace etc, stopping execution.

It should then be straightforward to find most of them through normal testing.

Mark

[marcnyc]

MarkR wrote:

By and large, you should write code which doesn't generate notices at all during normal operation.

Usually the way of doing this is by judicious use of (e.g.) isset(), but also occasional careful use of "@" operator (Beware: never call functions with @).

I made some time today to take care of the code and write it nicely to avoid those notices...
I have a question about coding:

if I have, say:

if ( $_SESSION["logged"] == 1 ) {
		return '  .: '.$_SESSION["user"].' ';
}

is it sufficient to add isset() around the variable?

	if ( isset($_SESSION["logged"]) == 1 ) {
		return '  .: '.$_SESSION["user"].' ';
	}

or do I have to do it in two steps?

if ( isset($_SESSION["logged"]) && $_SESSION["logged"] == 1 ) {
		return '  .: '.$_SESSION["user"].' ';
}

Thanks a lot

[marcnyc]

should I have posted this in "CODING" board?

[lozza1978]

Hi There,

session_start();
if ( $_SESSION["logged"] == 1 ) { 
        return '  .: '.$_SESSION["user"].' '; 
} 

would produce,
Notice: Undefined index: logged in C:\Program Files (x86)\Apache Group\Apache2\htdocs\errors.php on line 3.

if ( isset($_SESSION["logged"]) == 1 ) { 
        return '  .: '.$_SESSION["user"].' '; 
    } 

the code above will produce.
Notice: Undefined index: user in C:\Program Files (x86)\Apache Group\Apache2\htdocs\errors.php on line 4

if ( isset($_SESSION["logged"]) && $_SESSION["logged"] == 1 ) { 
        return '  .: '.$_SESSION["user"].' '; 
}

Will work as expected an not produce errors.

hope this helps.

lozza

[marcnyc]

so in other words, two steps is the way to go...
thanks

[lozza1978]

yes mate.. the 3rd option will not produce errors.