Posted by ZeldorBlat on 09/19/06 14:40

47computers@gmail.com wrote:
> > What do you mean by "mess up a line" ? Change it to include invalid
> > syntax?
>
> Ah, I see what you mean. When I "messed up a line" what I tried was a
> typo to a function call (on a result set from a mysqli->query call, I'd
> normally call fetch_assoc, but instead tried fletch_assoc, just to see
> how it would break). It looks like that was outside the scope of the
> custom error trapping capabilities.
>
> When I, instead, just change the name of a variable being used, then it
> traps a simple "undefined variable" error just fine.
>
> Well, I guess as long as some errors are untrappable, that's fine. On
> that note, does my trapping at least give me the full available scope?
> (error_reporting(E_ERROR | E_PARSE);)

Before the script is run it gets parsed which includes checking the
syntax. If the syntax is invalid, nothing happens -- at all.

>
> Also, for the errors outside of the custom error trapping scope (such
> as parser errors), the default response from the user's perspective is
> to just see a blank page. Is there any way to change that? Or maybe
> that's a result of something I changed early on and didn't quite know
> that would be an affect of my change?
>
> Basically, I'm just trying to make this website as user-friendly as
> possible in terms of handling errors and telling the users everything
> is ok (they kind of need their hands held sometimes), as well as
> reporting as many errors as possible to me in a more obvious manner,
> instead of just putting them in a log file.

Hopefully by the time your code gets into production you won't have any
syntax errors. You did at least try to run the script before putting
it out there, right?

[Back to original message]