[RESOLVED] fsockopen catch error

[Stobor]

Morning. Im trying to check if i can connect via telnet and echo a string depending on the result. The problem is it shows the error message followed by echoes

	$usenet = fsockopen($cfgServer, $cfgPort, $errno, $errstr, $cfgTimeOut);  	
if(!$usenet){ 	echo "failed"; 	echo "  ".date('H:i:s', time()+3600);} 	
else { echo "connected"; } 	

result

Warning: fsockopen(): unable to connect to 213...:* (A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) in C:\Program Files (x86)\EasyPHP-DevServer-13.1VC11\data\localweb\projects\Testing2.0\privatepingtelnet.php on line 17 failed 09:27:27

expected result

failed 09:27:27

How to properly catch the error ?

[Stobor]

Never mind

@fsockopen

[dalecosp]

It's not generally recommended to do that (@), but as long as you are aware, I've nothing personal against the Q-n-D ;-)

That being said, you might be well-rewarded (depending on how much of your work is PHP-related) to look at PHP's error handling[/code] in general, or [url=http://php.net/manual/en/language.exceptions.php]the Exceptions section if you have PHP 5 (which you should if at all possible, I think).

When you said "fsockopen catch error", I did kind of assume you were actually calling try() .... catch() and had an issue, so I was interested in taking a look as I'm not actually using that construct as a habit myself just yet ... 🙂

[Stobor]

Tried actually trying to catch it , didn't do anything.

[NogDog]

Stobor;11033677 wrote:

Tried actually trying to catch it , didn't do anything.

Yeah, you'd have to actually implement a custom error handler that turns it into an exception. As far as I'm concerned, the "@" is not a big deal as long as you are explicitly checking the return value for an error and handling it yourself, as you are in this case. Purists may differ with me. 🙂

[bradgrafelman]

NogDog;11033679 wrote:

Yeah, you'd have to actually implement a custom error handler that turns it into an exception.

I wish PHP did a lot more with exceptions retroactively rather than only moving forward. Either way, I suppose one might load a file via auto_prepend_file that looks like:

<?php
function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
}
set_error_handler("exception_error_handler");

to take care of that.

(Now that I think about that, it actually seems pretty nifty... not sure how backwards-compatible it is, though.)

NogDog;11033679 wrote:

As far as I'm concerned, the "@" is not a big deal as long as you are explicitly checking the return value for an error and handling it yourself, as you are in this case.

Agreed. Suppressing errors for the sake of gracefully handling them is one thing. Suppressing errors for the sake of hiding errors (e.g. sweeping them under the rug), however, is not.

[johanafm]

bradgrafelman;11033681 wrote:

Agreed. Suppressing errors for the sake of gracefully handling them is one thing. Suppressing errors for the sake of hiding errors (e.g. sweeping them under the rug), however, is not.

Except that the supressing errors to handle them might inadvertently lead to sweeping others under the rug.

$f = @fsockopen(TypoClass::ip);
if (!$f) error_log('fsockopen failed');

Since @ will now hide
Fatal error: Class 'TypoClass' not found

As long as the script is short and stand alone, it will most likely cause no problems. But if (when) you make it part of a larger context, or make it callable from elsewhere you risk having hard to find errors or no notification of them.