lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Mar 19, 2013 at 9:34 PM, William Sumner <prestonsumner@me.com> wrote:
> On Mar 19, 2013, at 6:56 PM, Kaj Eijlers <bizziboi@gmail.com> wrote:
>
>> The fact that the bug can go silently and only reveal itself later goes for 99% of algorithmic bugs.
>>
>> A function that can't handle a nil should check for it, not doing so is really programmer fault. No language can prevent programmer error. C just crashes, Lua silently accepts it, other languages try to handhold you more and start screaming and crying.
>>
>> Lua is very powerful, and with power comes responsibility. You can't blame the language for not dealing with programmer error.
>>
>> If that's what you want, you're maybe using the wrong language.
>
> This seems like a philosophical answer that assumes the language would somehow lose power if it reported an error for for this type of bug. Obviously, languages prevent programmer mistakes all the time by reporting errors, including Lua. The fact that static analyzers have been created to detect this, and code written to work around it, suggests that it is a legitimate issue caused by the lack of error-reporting for undefined variable accesses.
>
> Preston

No one disagrees it's a legitimate issue, but do you blame C for a
lack of error reporting for uninitialized memory accesses, or do you
use Valgrind to find them? Not every solution has to be implemented in
the language core. It's completely acceptable for an external tool to
provide techniques to resolve the problem.

Besides, accessing uninitialized locals/keys is only half of the
problem with making a typo on a variable name. Far more insidious is a
typo on an ASSIGNMENT, where no amount of language trickery could ever
detect the problem unless you REALLY want to force explicit separation
between declaration and initialization for /table members/.

/s/ Adam