Forums Bug Reports $ferr is not reporting error

When using /fopen with the -n switch, which ensures to fail if the file exists, none of the error-reporting identifiers return true. $ferr returns 0 and $fopen().err return $null. Additionally the file handle closes on its own - I am not sure if that this new behavior is intentional, but it possess compatibility problems.

/fopen -n should definitely set $ferr on an error, this seems like a regression to me.

However, as far as "closing the handle" goes, the "new" behaviour is correct. If the /fopen fails, it's impossible for the file handle to actually be opened, so the old (6.35) behaviour makes no sense. You can't actually close a file handle that wasn't even properly opened, so you should not be writing that kind of code even if it might accidentally work in older versions.

In general, you should be verifying that your handle is actually opened before attempting to close it (or do anything with it, frankly)-- if you aren't, it is a bug in your code. Note that the new behaviour is consistent with other open/close based transactions-- for example, "//comopen x INVALID | comclose x" will yield the same error. Perhaps a better /fclose error message (one more similar to /comclose on an invalid handle) would be better, though.

Of course you should be checking that the input is correct – that's common sense. When the handle was left open one could still call $fopen(<handle>).err, this is no longer possible. The change is indeed logical but does have that tiny side effect which I felt important enough to note, that's all.

I'm curious, in 6.35, for how long was the handle left open for? Until it was closed? Or until the script process ended? If it was left open indefinitely, this is wrong. If mIRC just waited until the end of the script to close it, that might not be such a bad behaviour.

The change in behaviour is due to your suggestion in this thread. As the file handle is automatically closed if it fails to open, error information is no longer available for that event. In retrospect, it was working correctly before - it is up to the scripter to check for errors and close the handle themselves - so I will be reverting this change in the next version.

Ah that's right; there were strange behaviors involving the handle that was left open - I forgot about that. I was not aware it affected $ferr in the process. The automatic closing of the file handle is indeed the correct behavior. Is it possible to just keep the value of $ferr last until the end of current scripting execution (detached from the file handle)? That way the handle will be closed to prevent any illogical operations while still making error handling possible.

I made the mistake of bringing that behavior up. I was just wondering on whether it was intentional. My bug report was just a concerns about $ferr. The handle behavior should remain as it makes more sense that if /fopen fails, there is no handle.

I am afraid this change should not have been made in the first place, for backwards-compatiblity reasons. The /fopen command had been working that way since 2003 and was stable. After the change, older scripts that did correctly perform an /fclose now display an error and halt. Currently, both $feof and $ferr only return results for handles that exist and return 0 otherwise. If I change them so that they are independent, global values, returning persistent results, this may have other side-effects on existing scripts. Since this change was only introduced recently in v7.22, it will be reverted for the next version.