[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Getting a table from commandline output
- From: "Ashwin Hirschi" <lua-l@...>
- Date: Tue, 08 Nov 2011 01:32:23 +0100
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"
"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?