I sometimes get an error writing to a file as the file is currently locked by another programm accessing it.
(File is misused as “mailbox” for data exchange from mAirlist to the other program)
Whatsoever, my thought is to initiate a second write attempt if the file is currently locked via the ‘except’ portion of the code.
If I understand well, a try-except-finally-end construction has to be programmed as a nested try-try-except-end-finally-end construct.
Question is what happens if file access fails in the except section?
Will the program just break or does the ‘finally’ section get executed in any case.
Example below:
...
if (PlayerIndex = 0) then begin
sl := TStringList.Create;
try
sl.Add('3')
try
sl.SaveToFile('C:\LPT_Out\DF_4.txt');
except
sl.SaveToFile('C:\LPT_Out\DF_4.txt');
end;
finally
sl.Free;
end;
end;
...
Of course a sleep was already considered, I just had to check what timer intervall the other program uses. Therefore I did not include it yet.
OK, one last question (hopefully) regarding mAirList; will I see an error entry in the log if the exception is thrown?
I mean if the (first) write command in the ‘try’ section fails.
When the (second) cmd in the exception hits the lock, I assume an error is logged.
I’m not certain about this, but I think you have to add your own SystemLog statement to the except code if you want to see the exception in the mAirList system log.
Remember that mAirList uses RemObjects PascalScript to execute scripts: it’s NOT ‘full’ Delphi, though it does use Delphi-style Pascal syntax.
So that means that my kludge would have worked if I only see a single entry in the log.
Whereas a double entry would tell me it failed to write the file at all.
No, you will never see a double error message. Because you’re handling the exception from the first call - but only unhandled exceptions (those which terminate the script execution) are displayed in the system log. If you want a notice to be displayed when the first call fails, you must insert a SystemLog command right before the second call:
Generally, when an exception occurs within a try…except…end block, the execution jumps to code in the except block, which is known as handling the exception. Thereafter, execution continues below the try…except…end block.
If an exception occurs outside a try…except…end block (there is no try…except around it), the exception is unhandled, execution is terminated, and mAirList will display the exception message in the system log.
try…except…end blocks can be nested. So basically, when another exception occurs in the except block, it is regarded as an unhandled exception, unless you wrap into into another (nested) try…except…end block, adding a handler for it.
The code in the finally…end block is always executed, even if an unhandled exception occurs. This is why you should add a try…finally…end block for each object you create (like the TStringList one in your script), putting the Free call into the finally block.
Adding a systemlog entry in the exception block seems to be useless (to me), as the first exception already triggers an entry to the log.
Failure of the exceptionblock to write to the file would require another nested try-block and corresponding write to the log (if required).
I can live with that, as I know the timer interval of the other program accessing the file.
So if I hit the exception, a sleep command which is out of sync with the other program will/should probably do it.
No, that should never happen. An error message will only appear for unhandled exceptions which terminate the execution.
Try this minimal example - what do you see in the log? (For scripts run manually through the Open menu, the message will be displayed in a dialog box rather than the system log, by the way.)
