By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,092 Members | 1,546 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,092 IT Pros & Developers. It's quick & easy.

Understanding error masking in error handling...

P: n/a
Hey all :)

I was wondering about the $error_types (I particularly notice the 's' suffix
when reading the manual) parameter for 'set_error_handler()':

Can be used to mask the triggering of the error_handler function just like
the error_reporting ini setting controls which errors are shown. Without
this mask set the error_handler will be called for every error regardless
to the setting of the error_reporting setting.

And, in my php.ini I have,
error_reporting = E_ALL & ~E_NOTICE

Which - I think - means something like "E_ALL and less severe AND NOT
E_NOTICE in particular".

This may be read wrong, but in essence, what I assume is possible is to
create a mask that very particularly lets you define which errors to handle
with your custom error handler, and which not to. But I cannot find any
documentation telling me how this works.

I would like, rather than having to do something like -

if (DEVELOPMENT_MODE && in_array($error_level, array(E_WARNING,
E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE, E_RECOVERABLE_ERROR,
E_DEPRECATED, E_USER_DEPRECATED)) log_to_screen($message);

- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.

This may seem superfluous, but what I'm creating right now are core services
that should service upwards of hundreds of frontends simultaneously, so
whatever small performance gain I can achieve here and there may lead to a
tremendous effect overall.

Can anyone help me with understanding this masking business? Or I have I
misunderstood the concept entirely? :)

Thanks in advance,
Daniel :)
Nov 7 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Daniel Smedegaard Buus schreef:
Hey all :)

I was wondering about the $error_types (I particularly notice the 's' suffix
when reading the manual) parameter for 'set_error_handler()':

Can be used to mask the triggering of the error_handler function just like
the error_reporting ini setting controls which errors are shown. Without
this mask set the error_handler will be called for every error regardless
to the setting of the error_reporting setting.

And, in my php.ini I have,
error_reporting = E_ALL & ~E_NOTICE

Which - I think - means something like "E_ALL and less severe AND NOT
E_NOTICE in particular".

This may be read wrong, but in essence, what I assume is possible is to
create a mask that very particularly lets you define which errors to handle
with your custom error handler, and which not to. But I cannot find any
documentation telling me how this works.

I would like, rather than having to do something like -

if (DEVELOPMENT_MODE && in_array($error_level, array(E_WARNING,
E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE, E_RECOVERABLE_ERROR,
E_DEPRECATED, E_USER_DEPRECATED)) log_to_screen($message);

- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.

This may seem superfluous, but what I'm creating right now are core services
that should service upwards of hundreds of frontends simultaneously, so
whatever small performance gain I can achieve here and there may lead to a
tremendous effect overall.

Can anyone help me with understanding this masking business? Or I have I
misunderstood the concept entirely? :)

Thanks in advance,
Daniel :)
Hi Daniel,

I think you need to reread the manual:
http://nl3.php.net/manual/en/functio...or-handler.php

It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect and
your error handler will be called regardless - however you are still
able to read the current value of error_reporting and act appropriately.
Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator.
So your custom errorhandler is called ALWAYS regardless the settings you
put into error_reporting() (or via php.ini).

Your errorhandler must deal with this error then.
The errorhandler is called with a bunch of parameters, the first being
the errornumber as listed here:
http://nl3.php.net/manual/en/functio...-reporting.php

So I am unsure why you care about the 'masking business', since it is of
no concern to you (unless I completely misinterpret your posting).

The passed errornumber can only be 1 of the errors listed (You cannot
have 2 errors at the same time).

Also, if you write your own handler, be sure you check for errorsupression.

Here is the first peice of code of an errorhandler I use often:

function errorHandler($number, $string, $file, $line, $context) {
// If the user uses errorsurperrsion with @, we need to forgive this error!
if (error_reporting() == 0){
// The error was surpressed, return without futher interference.
return;
}
// rest of the errorhandler

}

Good luck,

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Nov 7 '08 #2

P: n/a
Erwin Moller wrote:
Daniel Smedegaard Buus schreef:
>Hey all :)

I was wondering about the $error_types (I particularly notice the 's'
suffix when reading the manual) parameter for 'set_error_handler()':

Can be used to mask the triggering of the error_handler function just
like the error_reporting ini setting controls which errors are shown.
Without
this mask set the error_handler will be called for every error
regardless to the setting of the error_reporting setting.

And, in my php.ini I have,
error_reporting = E_ALL & ~E_NOTICE

Which - I think - means something like "E_ALL and less severe AND NOT
E_NOTICE in particular".

This may be read wrong, but in essence, what I assume is possible is to
create a mask that very particularly lets you define which errors to
handle with your custom error handler, and which not to. But I cannot
find any documentation telling me how this works.

I would like, rather than having to do something like -

if (DEVELOPMENT_MODE && in_array($error_level, array(E_WARNING,
E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE, E_RECOVERABLE_ERROR,
E_DEPRECATED, E_USER_DEPRECATED)) log_to_screen($message);

- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.

This may seem superfluous, but what I'm creating right now are core
services that should service upwards of hundreds of frontends
simultaneously, so whatever small performance gain I can achieve here and
there may lead to a tremendous effect overall.

Can anyone help me with understanding this masking business? Or I have I
misunderstood the concept entirely? :)

Thanks in advance,
Daniel :)

Hi Daniel,

I think you need to reread the manual:
http://nl3.php.net/manual/en/functio...or-handler.php

It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect and
your error handler will be called regardless - however you are still
able to read the current value of error_reporting and act appropriately.
Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator.
Actually, I did read the manual ;) and this part too, but I'm not using
error_reporting(), I'm referring to the last parameter in
set_error_handler(callback $error_handler [, int $error_types]), which is,
and I quote (http://dk2.php.net/set_error_handler),

error_types

Can be used to mask the triggering of the error_handler function just like
the error_reporting ini setting controls which errors are shown. Without
this mask set the error_handler will be called for every error regardless
to the setting of the error_reporting setting.
Which is, in fact, the same quote as in my previous post ;) So, this has the
same effect as error_reporting() would have on the built-in error handler,
only on the custom one.
So your custom errorhandler is called ALWAYS regardless the settings you
put into error_reporting() (or via php.ini).

Your errorhandler must deal with this error then.
The errorhandler is called with a bunch of parameters, the first being
the errornumber as listed here:
http://nl3.php.net/manual/en/functio...-reporting.php

So I am unsure why you care about the 'masking business', since it is of
no concern to you (unless I completely misinterpret your posting).

The passed errornumber can only be 1 of the errors listed (You cannot
have 2 errors at the same time).

Also, if you write your own handler, be sure you check for
errorsupression.

Here is the first peice of code of an errorhandler I use often:

function errorHandler($number, $string, $file, $line, $context) {
// If the user uses errorsurperrsion with @, we need to forgive this
error!
if (error_reporting() == 0){
// The error was surpressed, return without futher interference.
return;
}
// rest of the errorhandler
I did not know of this. Very useful tip! I have previously turned
error_reporting on and off on-the-fly to achieve the same! Thank you very
much :)

Daniel
}

Good luck,

Regards,
Erwin Moller
Nov 7 '08 #3

P: n/a
Daniel Smedegaard Buus schreef:
Erwin Moller wrote:
>Daniel Smedegaard Buus schreef:
>>Hey all :)

I was wondering about the $error_types (I particularly notice the 's'
suffix when reading the manual) parameter for 'set_error_handler()':

Can be used to mask the triggering of the error_handler function just
like the error_reporting ini setting controls which errors are shown.
Without
this mask set the error_handler will be called for every error
regardless to the setting of the error_reporting setting.

And, in my php.ini I have,
error_reporting = E_ALL & ~E_NOTICE

Which - I think - means something like "E_ALL and less severe AND NOT
E_NOTICE in particular".

This may be read wrong, but in essence, what I assume is possible is to
create a mask that very particularly lets you define which errors to
handle with your custom error handler, and which not to. But I cannot
find any documentation telling me how this works.

I would like, rather than having to do something like -

if (DEVELOPMENT_MODE && in_array($error_level, array(E_WARNING,
E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE, E_RECOVERABLE_ERROR,
E_DEPRECATED, E_USER_DEPRECATED)) log_to_screen($message);

- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.

This may seem superfluous, but what I'm creating right now are core
services that should service upwards of hundreds of frontends
simultaneously, so whatever small performance gain I can achieve here and
there may lead to a tremendous effect overall.

Can anyone help me with understanding this masking business? Or I have I
misunderstood the concept entirely? :)

Thanks in advance,
Daniel :)
Hi Daniel,

I think you need to reread the manual:
http://nl3.php.net/manual/en/functio...or-handler.php

>It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect and
your error handler will be called regardless - however you are still
able to read the current value of error_reporting and act appropriately.
Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator.

Actually, I did read the manual ;) and this part too, but I'm not using
error_reporting(), I'm referring to the last parameter in
set_error_handler(callback $error_handler [, int $error_types]), which is,
and I quote (http://dk2.php.net/set_error_handler),

error_types

Can be used to mask the triggering of the error_handler function just like
the error_reporting ini setting controls which errors are shown. Without
this mask set the error_handler will be called for every error regardless
to the setting of the error_reporting setting.

Which is, in fact, the same quote as in my previous post ;) So, this has the
same effect as error_reporting() would have on the built-in error handler,
only on the custom one.
Hi,

Sorry to be so thick, but I do not understand what your problem is then.
You can overrule the default errorhandler (with its associated default
error_reporting levels) with you own customn errorhandler (with it
associated error_reporting levels passed to the function.).

This is your core 'problem', right?:
[quote]
- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.
[/qoute]

So you pass a value to it for the mask:
(as defined here: http://nl3.php.net/manual/en/functio...-reporting.php)
value constant
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
6143 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR
8192 E_DEPRECATED
16384 E_USER_DEPRECATED

So, for example, if you want to catch E_WARNING and E_NOTICE: you look
up their values, add them, and pass that value. In this case 2+8=12.

But I have this feeling that I still don't understand what your problem
is. ;-)

<snip>
>Also, if you write your own handler, be sure you check for
errorsupression.

Here is the first peice of code of an errorhandler I use often:

function errorHandler($number, $string, $file, $line, $context) {
// If the user uses errorsurperrsion with @, we need to forgive this
error!
if (error_reporting() == 0){
// The error was surpressed, return without futher interference.
return;
}
// rest of the errorhandler

I did not know of this. Very useful tip! I have previously turned
error_reporting on and off on-the-fly to achieve the same! Thank you very
much :)
Glad to hear that.
I found the solution to this 'problem' the hard way: ADODB (my favorite
database abstractionlayer) created errors in my application. When I
removed my own errorhandling the error were gone.
So I look at the line where the error originated, and they all had a @
in them. So I reread the whole errorhandling thingy on php.net, and it
actually says it quite clearly. But appearantly you missed it too.
Methinks the editors should put that part in BOLD. ;-)

Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Nov 10 '08 #4

P: n/a
Erwin Moller wrote:
Hi,

Sorry to be so thick, but I do not understand what your problem is then.
Hehe, no worries, I may very well be the one who is thick here (in addition
to me putting on a few early Christmas pounds), because my whole problem is
basically that I don't understand the whole masking business :)
[quote]
You can overrule the default errorhandler (with its associated default
error_reporting levels) with you own customn errorhandler (with it
associated error_reporting levels passed to the function.).

This is your core 'problem', right?:
- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.
[/qoute]

So you pass a value to it for the mask:
(as defined here:
http://nl3.php.net/manual/en/functio...-reporting.php)
value constant
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
6143 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR
8192 E_DEPRECATED
16384 E_USER_DEPRECATED

So, for example, if you want to catch E_WARNING and E_NOTICE: you look
up their values, add them, and pass that value. In this case 2+8=12.
Yes, and now, because I don't believe (or, don't hope that) this is the
whole masking business. I'm thinking that the masking thing is a
bit-shifting thing that makes it possible to say yes please to E_WARNING
(2) and E_NOTICE (8), but NOT to E_PARSE (4), and thus it's not 2+8=10, but
some kind of shifting, which would explain the "squared leaps" in error
numbers instead of just 1,2,3,4,..., and also the "error_reporting =
E_ALL & ~E_NOTICE" which is definitely not a simple addition of error level
values.

That is my whole entire question. How does the masking business work? If
it's not just adding numbers, which I'm pretty sure it isn't :)

Daniel
But I have this feeling that I still don't understand what your problem
is. ;-)

<snip>
>>Also, if you write your own handler, be sure you check for
errorsupression.

Here is the first peice of code of an errorhandler I use often:

function errorHandler($number, $string, $file, $line, $context) {
// If the user uses errorsurperrsion with @, we need to forgive this
error!
if (error_reporting() == 0){
// The error was surpressed, return without futher interference.
return;
}
// rest of the errorhandler

I did not know of this. Very useful tip! I have previously turned
error_reporting on and off on-the-fly to achieve the same! Thank you very
much :)

Glad to hear that.
I found the solution to this 'problem' the hard way: ADODB (my favorite
database abstractionlayer) created errors in my application. When I
removed my own errorhandling the error were gone.
So I look at the line where the error originated, and they all had a @
in them. So I reread the whole errorhandling thingy on php.net, and it
actually says it quite clearly. But appearantly you missed it too.
Methinks the editors should put that part in BOLD. ;-)

Regards,
Erwin Moller

Nov 10 '08 #5

P: n/a
On Mon, 10 Nov 2008 23:09:56 +0100, da****@danielsmedegaardbuus.dk
wrote:[quote]
Erwin Moller wrote:
Hi,

Sorry to be so thick, but I do not understand what your problem is then.

Hehe, no worries, I may very well be the one who is thick here (in addition
to me putting on a few early Christmas pounds), because my whole problem is
basically that I don't understand the whole masking business :)
You can overrule the default errorhandler (with its associated default
error_reporting levels) with you own customn errorhandler (with it
associated error_reporting levels passed to the function.).

This is your core 'problem', right?:
- on every error/notice/whatever comes by my custom error handler, to be
able to specify a mask that essentially does the same only in my
set_error_handler call.
[/qoute]

So you pass a value to it for the mask:
(as defined here:
http://nl3.php.net/manual/en/functio...-reporting.php)
value constant
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
6143 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR
8192 E_DEPRECATED
16384 E_USER_DEPRECATED

So, for example, if you want to catch E_WARNING and E_NOTICE: you look
up their values, add them, and pass that value. In this case 2+8=12.

Yes, and now, because I don't believe (or, don't hope that) this is the
whole masking business. I'm thinking that the masking thing is a
bit-shifting thing that makes it possible to say yes please to E_WARNING
(2) and E_NOTICE (8), but NOT to E_PARSE (4), and thus it's not 2+8=10, but
some kind of shifting, which would explain the "squared leaps" in error
numbers instead of just 1,2,3,4,..., and also the "error_reporting =
E_ALL & ~E_NOTICE" which is definitely not a simple addition of error level
values.

That is my whole entire question. How does the masking business work? If
it's not just adding numbers, which I'm pretty sure it isn't :)
Right, the basic way to approach this is having each option assigned
a value of 2^n, which gives us binary numbers like:

00000001 OPTION_ONE
00000010 OPTION_TWO
00000100 OPTION_THREE
00001000 OPTION_FOUR
00010000 OPTION_FIVE
00100000 OPTION_SIX
01000000 OPTION_SEVEN
10000000 OPTION_EIGHT

You can increase the bit length as necessary. I chose to align each
of the values as a byte.

Using bit-wise operators is natural here for PHP. Depending on which
bits are "on", that will determine which error levels are being
employed. We use the bitwise operators to determine the combination
of 1's and 0's we want. The constants (E_*) are convenient, because
they provide context, and allow the confusing-looking values to
remain internalized, and possibly changed without affecting us. This
is why I would not recommend directly dealing with the values
themselves.

// Turning on multiple options via OR'ing bits together
$bitstring = E_ALL | E_STRICT;

Here's how you look at it in binary (aligning both to word length).
OR'ing results in a 1 if either bit is 1, 0 otherwise. Note that
E_ALL is essentially a shortcut for turning on several options, which
PHP has provided for us. Notice how the bit where E_STRICT is set is
0 in E_ALL. This shows why we need to OR E_STRICT explicitly.

0001 0111 1111 1111 (E_ALL = 6143 base 10)
OR
0000 1000 0000 0000 (E_STRICT = 2048 base 10)
-------------------
0001 1111 1111 1111 (E_ALL | E_STRICT = 8191 base 10)

I suggest you search for a tutorial on bitwise operations on the Web.
This concept is used fairly often in many languages.

[snip]

--
Curtis
$email = str_replace('sig.invalid', 'gmail.com', $from);
Nov 11 '08 #6

P: n/a
Curtis wrote:
[quote]
On Mon, 10 Nov 2008 23:09:56 +0100, da****@danielsmedegaardbuus.dk
wrote:
>Erwin Moller wrote:
Hi,

Sorry to be so thick, but I do not understand what your problem is
then.

Hehe, no worries, I may very well be the one who is thick here (in
addition to me putting on a few early Christmas pounds), because my whole
problem is basically that I don't understand the whole masking business
:)
You can overrule the default errorhandler (with its associated default
error_reporting levels) with you own customn errorhandler (with it
associated error_reporting levels passed to the function.).

This is your core 'problem', right?:
- on every error/notice/whatever comes by my custom error handler, to
be
able to specify a mask that essentially does the same only in my
set_error_handler call.
[/qoute]

So you pass a value to it for the mask:
(as defined here:
http://nl3.php.net/manual/en/functio...-reporting.php)
value constant
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
6143 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR
8192 E_DEPRECATED
16384 E_USER_DEPRECATED

So, for example, if you want to catch E_WARNING and E_NOTICE: you look
up their values, add them, and pass that value. In this case 2+8=12.

Yes, and now, because I don't believe (or, don't hope that) this is the
whole masking business. I'm thinking that the masking thing is a
bit-shifting thing that makes it possible to say yes please to E_WARNING
(2) and E_NOTICE (8), but NOT to E_PARSE (4), and thus it's not 2+8=10,
but some kind of shifting, which would explain the "squared leaps" in
error
numbers instead of just 1,2,3,4,..., and also the "error_reporting =
E_ALL & ~E_NOTICE" which is definitely not a simple addition of error
level values.

That is my whole entire question. How does the masking business work? If
it's not just adding numbers, which I'm pretty sure it isn't :)

Right, the basic way to approach this is having each option assigned
a value of 2^n, which gives us binary numbers like:

00000001 OPTION_ONE
00000010 OPTION_TWO
00000100 OPTION_THREE
00001000 OPTION_FOUR
00010000 OPTION_FIVE
00100000 OPTION_SIX
01000000 OPTION_SEVEN
10000000 OPTION_EIGHT

You can increase the bit length as necessary. I chose to align each
of the values as a byte.

Using bit-wise operators is natural here for PHP. Depending on which
bits are "on", that will determine which error levels are being
employed. We use the bitwise operators to determine the combination
of 1's and 0's we want. The constants (E_*) are convenient, because
they provide context, and allow the confusing-looking values to
remain internalized, and possibly changed without affecting us. This
is why I would not recommend directly dealing with the values
themselves.

// Turning on multiple options via OR'ing bits together
$bitstring = E_ALL | E_STRICT;

Here's how you look at it in binary (aligning both to word length).
OR'ing results in a 1 if either bit is 1, 0 otherwise. Note that
E_ALL is essentially a shortcut for turning on several options, which
PHP has provided for us. Notice how the bit where E_STRICT is set is
0 in E_ALL. This shows why we need to OR E_STRICT explicitly.

0001 0111 1111 1111 (E_ALL = 6143 base 10)
OR
0000 1000 0000 0000 (E_STRICT = 2048 base 10)
-------------------
0001 1111 1111 1111 (E_ALL | E_STRICT = 8191 base 10)

I suggest you search for a tutorial on bitwise operations on the Web.
This concept is used fairly often in many languages.

[snip]
Ah, this was exactly what I was hoping for :) And easy to understand, too!
Thank you so much! :)

May I ask what the AND operator does? And the ~ in front of a constant, is
that only for the php.ini setting, or is that also valid in php, and if so,
what does it mean?

Thank you very much, Curtis, for the explanation :)

Daniel
Nov 11 '08 #7

P: n/a
On Tue, 11 Nov 2008 08:45:36 +0100, Daniel Smedegaard Buus
<da****@danielsmedegaardbuus.dkwrote in
<49***********************@news.sunsite.dk>:

[snip explanation of bit fields]
>May I ask what the AND operator does?
Assuming that you mean the "&" operator, it keeps only the bits that
are set in both variables. E.g. 2 & 3 = 2

00000010 // 2 base 2
00000011 // 3 base 2
--------
00000010 // keeps only the bit in the two's place
// because it's the only one set in both

>And the ~ in front of a constant, is that only for the php.ini
setting, or is that also valid in php, and if so, what does it mean?
It's the complement operator, which inverts the bits. E.g. if 2 is
00000010 then it's complement is 11111101. It's useful for removing a
bit from a bitfield. Saying E_ALL & ~ E_NOTICE is a way of saying
"everything except for notices".
--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
(703) 580-0210 | Project Management
Nov 11 '08 #8

P: n/a
On Tue, 11 Nov 2008 08:45:36 +0100, da****@danielsmedegaardbuus.dk
wrote:[quote]
Curtis wrote:
On Mon, 10 Nov 2008 23:09:56 +0100, da****@danielsmedegaardbuus.dk
wrote:
Erwin Moller wrote:

Hi,

Sorry to be so thick, but I do not understand what your problem is
then.

Hehe, no worries, I may very well be the one who is thick here (in
addition to me putting on a few early Christmas pounds), because my whole
problem is basically that I don't understand the whole masking business
:)

You can overrule the default errorhandler (with its associated default
error_reporting levels) with you own customn errorhandler (with it
associated error_reporting levels passed to the function.).

This is your core 'problem', right?:
- on every error/notice/whatever comes by my custom error handler, to
be
able to specify a mask that essentially does the same only in my
set_error_handler call.
[/qoute]

So you pass a value to it for the mask:
(as defined here:
http://nl3.php.net/manual/en/functio...-reporting.php)
value constant
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
6143 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR
8192 E_DEPRECATED
16384 E_USER_DEPRECATED

So, for example, if you want to catch E_WARNING and E_NOTICE: you look
up their values, add them, and pass that value. In this case 2+8=12.


Yes, and now, because I don't believe (or, don't hope that) this is the
whole masking business. I'm thinking that the masking thing is a
bit-shifting thing that makes it possible to say yes please to E_WARNING
(2) and E_NOTICE (8), but NOT to E_PARSE (4), and thus it's not 2+8=10,
but some kind of shifting, which would explain the "squared leaps" in
error
numbers instead of just 1,2,3,4,..., and also the "error_reporting =
E_ALL & ~E_NOTICE" which is definitely not a simple addition of error
level values.

That is my whole entire question. How does the masking business work? If
it's not just adding numbers, which I'm pretty sure it isn't :)
[explanation snipped]
Ah, this was exactly what I was hoping for :) And easy to understand, too!
Thank you so much! :)

May I ask what the AND operator does? And the ~ in front of a constant, is
that only for the php.ini setting, or is that also valid in php, and if so,
what does it mean?

Thank you very much, Curtis, for the explanation :)

Daniel
I'm glad the explanation helped. :)

I'll leave you to read Charles Calvert's response on the bitwise &
and ~ (1's complement) operator.
--
Curtis
$email = str_replace('sig.invalid', 'gmail.com', $from);
Nov 12 '08 #9

P: n/a
Charles Calvert wrote:
On Tue, 11 Nov 2008 08:45:36 +0100, Daniel Smedegaard Buus
<da****@danielsmedegaardbuus.dkwrote in
<49***********************@news.sunsite.dk>:

[snip explanation of bit fields]
>>May I ask what the AND operator does?

Assuming that you mean the "&" operator, it keeps only the bits that
are set in both variables. E.g. 2 & 3 = 2

00000010 // 2 base 2
00000011 // 3 base 2
--------
00000010 // keeps only the bit in the two's place
// because it's the only one set in both

>>And the ~ in front of a constant, is that only for the php.ini
setting, or is that also valid in php, and if so, what does it mean?

It's the complement operator, which inverts the bits. E.g. if 2 is
00000010 then it's complement is 11111101. It's useful for removing a
bit from a bitfield. Saying E_ALL & ~ E_NOTICE is a way of saying
"everything except for notices".
Yes, thank you both :) I did the obligatory Googling, and ended up with an
extremely explanatory C tutorial on bitwise operations, and luckily, this
applies 1:1 on PHP :)

Funny, from the outside it seems like a bad thing to be happy that you just
made handling of errors in your code faster ;) He he. Well, we gotta be
realistic beings, right? ;)

Another funny thing is that reading this, everything just fell into place.
I've been taught this as part of my education, specifically when learning
assembly language, but for some reason it just doesn't stick with me... I
really like languages like Ruby :D

Either way, It's great to revisit basic stuff like this, because it really
adds a lot of understanding to knowing what you're actually doing when you
declare a class or use something basic like control structures. It's really
healthy to learn this, you know :)

Cheers to you both,
Daniel :)
Nov 12 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.