[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Getting a table from commandline output
- From: HyperHacker <hyperhacker@...>
- Date: Mon, 7 Nov 2011 20:36:43 -0700
On Mon, Nov 7, 2011 at 17:32, Ashwin Hirschi <email@example.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"
> "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?
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.