On the usage of "@" (error control operator)

[Leonardo Azpurua]

Hi,

A few weeks ago, I wrote this sentence:

@$retVal = $this->lastfetch[$ndx];

Yesterday, browsing the manual, I found this paragraph:

"PHP supports one error control operator: the at sign (@). _When prepended
to an expression_ in PHP, any error messages that might be generated by that
expression will be ignored."

and, a few lines further:

"A simple rule of thumb is: if you can take the value of something, you can
prepend the @ operator to it."

Since an assigment is not an expression, the required syntax should be:

$retVal = @$this->lastfetch[$ndx];

But both forms work.


Is there any reason to prefer one above the other?

--

[Jerry Stuckle]

My preference is to not use it at all and fix the error.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

[Shake]

Both forms works, but not both forms are the same:

$retVal = @$this->lastfetch[$ndx];

(....errors ignored....)

@$retVal = $this->lastfetch[$ndx];

(.........Errors ignored.........)


Perhaps in some cases "$retVal" could throw a type casting error or
something of this kind.

Rgds.

[Leonardo Azpurua]

"Jerry Stuckle" <jstu...@attglobal.net> escribió en el mensaje
news:jpiq01$km7$1...@dont-email.me...
>> [snip]

>> Since an assigment is not an expression, the required syntax should be:
>>
>> $retVal = @$this->lastfetch[$ndx];
>>
>> But both forms work.
>>
>>
>> Is there any reason to prefer one above the other?
>>
>> --
>>
>>
>
> My preference is to not use it at all and fix the error.
>

Hi,

In this case there is no error to fix.

I am writing (mostly for study purposes) a Web Interface to the reports of a
business system of mine. This reports are generated from a user-generated
script contained in a text file.

Data items may come from several sources, like script defined variables,
predefined variables, input parameters, database columns or script defined
formulas.

So, I must search an identifier in several associative arrays. And trying to
access an array element with an invalid index triggers an error.

An alternative would be to walk the array comparing each key with the
desired identifier, but it means more code and, probably, less efficiency
(even with the overhead of the @ operator).

Anyway, any advice regarding a cleaner way to do this, will be very
appreciated.

Thanks!

[Leonardo Azpurua]

"Shake" <QUIT...@QUITAESTO.NOES> escribió en el mensaje
news:jpir8f$til$1...@dont-email.me...

Thanks.

Is there any chance that a type casting error occurs in such a statement?

--

[Shake]

El 23/05/2012 16:52, Leonardo Azpurua escribió:
>>
>> Perhaps in some cases "$retVal" could throw a type casting error or
>> something of this kind.
>
> Thanks.
>
> Is there any chance that a type casting error occurs in such a statement?
>

Don't know. Was only an Idea... a suspect, that that could happen (not
necesarily with type casting).

Rgds.

[Leonardo Azpurua]

"Shake" <QUIT...@QUITAESTO.NOES> escribió en el mensaje

news:jpiuno$kih$1...@dont-email.me...

Yup. Got the idea.

Thanks, again.

[Jerry Stuckle]

What type casting error? Or are you just guessing?

[Jerry Stuckle]

On 5/23/2012 10:49 AM, Leonardo Azpurua wrote:
> "Jerry Stuckle"<jstu...@attglobal.net> escribió en el mensaje
> news:jpiq01$km7$1...@dont-email.me...
>>> [snip]
>>> Since an assigment is not an expression, the required syntax should be:
>>>
>>> $retVal = @$this->lastfetch[$ndx];
>>>
>>> But both forms work.
>>>
>>>
>>> Is there any reason to prefer one above the other?
>>>
>>> --
>>>
>>>
>>
>> My preference is to not use it at all and fix the error.
>>
>
> Hi,
>
> In this case there is no error to fix.
>
> I am writing (mostly for study purposes) a Web Interface to the reports of a
> business system of mine. This reports are generated from a user-generated
> script contained in a text file.
>
> Data items may come from several sources, like script defined variables,
> predefined variables, input parameters, database columns or script defined
> formulas.
>
> So, I must search an identifier in several associative arrays. And trying to
> access an array element with an invalid index triggers an error.
>

Then there is an error. So, the solution is to check to see if the
element exists before trying to access it.

> An alternative would be to walk the array comparing each key with the
> desired identifier, but it means more code and, probably, less efficiency
> (even with the overhead of the @ operator).
>

Maybe, maybe not. It depends on a lot of factors.

> Anyway, any advice regarding a cleaner way to do this, will be very
> appreciated.
>
> Thanks!
>
>

[Leonardo Azpurua]

"Jerry Stuckle" <jstu...@attglobal.net> escribió en el mensaje

news:jpj296$bh7$1...@dont-email.me...

> On 5/23/2012 10:49 AM, Leonardo Azpurua wrote:
>> So, I must search an identifier in several associative arrays. And trying
>> to
>> access an array element with an invalid index triggers an error.

Hi,

I might have a valid index or not. And if it is valid, it could be valid on
one among several arrays.

Anyway, I just learnt that isset($arr[$ndx]) does not fire an error if $ndx
is not valid on $arr.

So, instead of

@$x = $arr[$ndx];
if (isset($x)) {
...
}

I should have written

if (isset($arr[$ndx])) {
$x = $arr[$ndx];
...
}

avoiding the rather ugly original construct.

Thanks!
--

[Jerry Stuckle]

Yup, that's what isset() is for. And this way looks a lot nicer, also :)

[Thomas Mlynarczyk]

Leonardo Azpurua schrieb:

> Since an assigment is not an expression

But it is in PHP! You can write, e.g.:

if ( is_file( $file = $dir . $name . $ext ) )
{
include $file;
}

Greetings,
Thomas


--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)