How to properly find what's wrong w/@oci_connect()

[AFTNHombre]

I have code that fails and goes like this:

$dbc = @oci_connect($This, $that, $theother);
if (!dbc) {
     $arr = oci_error();
     assert($arr);
}

That's just an abstraction. In fact, $arr comes up as false in this case. I don't think it should be because of the @, so why then could oci_error() return false when @oci_connect() just returned false? In the real code, there are no oci_ calls between @oci_connect() and oci_error().

[xyph]

You're making coding errors in your abstraction. It's hard to give you definitive answers without verifying the accuracy of actual code.

 

From what I understand, a FALSE return from oci_connect _should_ cause oci_error to return an array, rather than FALSE.

 

Since I don't have an Oracle server handy, I can't verify my assumptions. I can tell you that suppressing errors using @ is a bad idea. In live server situations, you should instead hide errors from being displayed, and log them in a file.

[AFTNHombre]

Errors, eh? I only count one. Ok, here's the concrete code:

$this->ocn = @oci_connect($_conn_uid,$_conn_pwd,$conn_server_host);

if (!$this->ocn)
{
Log::TraceOracleError(oci_error());

 

The way the code is setup right now the set_error_handler function throws an exception, if error_reporting() != 0. So changing that wouldn't work, we but could fairly easily catch the exception. But what's wrong w/@?

[xyph]

It suppresses errors. As a developer, seeing errors is generally important. When you're performing a non-critical action (ie: deleting a file that will get cleaned up by a garbage collector anyways), I suppose the @ suppressor isn't that bad. If you're handling errors in a proper manner, wouldn't seeing that and fixing your code be the more ideal solution?

 

I'm setting up an Oracle server now to test the results on my local machine.

 

Damn you Sun, making me register some useless web account to download your software >_<

[AFTNHombre]

If you're handling errors in a proper manner, wouldn't seeing that and fixing your code be the more ideal solution?

Isn't that what I'm trying to do? The most helpful information should be gotten from oci_error(), but since that's failing, it's hard to know what else to do.

[xyph]

This could be due to an error generated in oci_connect(), that for some reason or another is not changing the result of oci_error()

 

Suppressing errors is never the "right" way to handle them, regardless of the checks you may perform afterwards.

[AFTNHombre]

I saw that, too. But if you read further, you'll see that that opinion was disproved by induction.

[xyph]

Noticed that too. Posted before reading the whole thing. Oops.

 

Seems you're *sort of* not alone

https://forums.oracle.com/forums/thread.jspa?threadID=2262630

 

My guess is it's some sort of local misconfiguration, or a freak combination of Oracle/PHP/OS versions that seem to explode.

 

Posting in that forum would probably yield better advice to help narrow down the issue.