 |
lua-l archive |
|
|
||
|
On my cheapo Windows XP machine the lines-driven for-loop (as shown above) always comes to a screeching halt. Using a loop around a read "*l" call may look less elegant, but works just fine. Obviously, in the latter case the broken pipe situation is still there. It just doesn't bring the script to its knees, because no alert is thrown.By "bring the script to its knees" you mean that the script ends with a regular error condition?
I guess it depends... Do you consider the lines iterator throwing an alert - even though the reference manual makes no mention of this possibility whatsoever - a "regular error condition"? [;-)]
For the record, I think it's a tricky situation that's hard to improve upon. By their very nature, iterators need to have very defined behaviour. And in this case throwing an alert seems to be a sensible course of action.
But, since this behaviour is not documented, it catches people off guard. If you don't know the iterator can throw an error, there's no way to protect against it. So, if you're unlucky your script ends prematurely on a seemingly innocent looking piece of code! Hence my post.
Please note that the introduction to section "Input and Output Facilities" reads:
"Unless otherwise stated, all I/O functions return nil on failure (plus an error message as a second result and a system-dependent error code as a third result) and some value different from nil on success."
Perhaps it's an idea to mention the possibility of the lines iterator throwing an error in the manual?
Ashwin.