Re: Getting a table from commandline output

[HyperHacker <hyperhacker@...>]

On Mon, Nov 7, 2011 at 17:32, Ashwin Hirschi <lua-l@reflexis.com> wrote:
>
>>> 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.
>
>
>

Is an alert something that can be caught with pcall? That seems like
the most sensible way for an iterator to handle errors.

-- 
Sent from my toaster.