and the runtime output

Lua unfortunatly (imo) likes to co-erce things into strings and numbers when it can without explicitly being told to do so.

This depends entirely on the nature of the error. A major failure that is likely to really screw the works should abort with a truly meaningful message. Many languages allow explicit handling of such events and these should be used where possible. Not all possible error conditions can be forseen, but as many as can be should be given this treatment.

Lesser problems can usually be permitted to continue, though perhaps with a warning message and a return to an input field. A custom error handler, such as that mentioned by Chris Adams can help with both types of problems, but I need to ask Chris if he uses it only during debug, or if it remains in the finished code.

Rob Walker makes an excellent point when he says, “The last thing you want is to believe everything is fine meanwhile your data is quietly getting corrupted as the program continues.”

There is a real problem with programs that continue with no error control. Subtle errors can easily be introduced into data and soon an entire database is contaminated and totally useless. My primary background is in database programing and, trust me, this is a type of problem you do not want to discover after a client has invested thousands of dollars in data collection/entry efforts. If the language has no intrinsic method to validate data, the programmer must implicitly code data checking with appropriate action before that data is used or stored.

I prefer to accomplish this myself and specify the program response rather than depend only upon the language’s intrinsic type checking. I do have to admit, however, that I am rather a newcomer to web scripting, client or server, but this means I have no hard and fast favorites. Right now I am improving my JavaScript and just beginning with PHP, so for the most part, I will just sit back and learn from y’all.

Lee Eschen

If you want a stricter behavior use Hash#fetch instead of Hash#[].

Now the script will raise an IndexError.

PHP and perl are weak/dynamic.
Ruby and python are strong/dynamic.

And just for contrast:

C++ is weak/static
Java is strong/static

In terms of error reporting, I think we have known for quite awhile that Ruby is pretty crappy at it.

class Foo {}
$f = new Foo();
if (mt_rand(1, 100) == 1) $f->someMethod();

But in any case it should be a deliberate decision to let the program continue, not the default behavior of the language. The last thing you want is to believe everything is fine meanwhile your data is quietly getting corrupted as the program continues.

Well put. This is one of the reasons I’ve never been a fan of MySQL (but that’s a whole other discussion…)

You can still consider dynamic languages appropriate in a FailFast context.

Well, first of all, I was playing devil’s advocate; I’m a fan of both dynamically-typed languages AND statically typed ones (different tools for different tasks). I was attempting to point out the fact that FailFast isn’t a black or white philosophy (as it seems that doug above is a fan of absolutes). There are degrees of failing fast, and while it’s a good general approach, obviously sometimes other considerations take priority.

It’s not about type checking.

I disagree. It’s not ONLY about type checking, but type errors *are* a common source of application bugs. Catching a parameter with an incorrect type at the beginning of a method invocation (say, with a type hint) is “fail fast” when compared with not checking the type and then 20-30 lines of code later attempting to call an undefined method on that parameter. If you are one to see “fail fast” as an absolute rule, then obviously you would prefer to know as soon as the method is called that the parameter type is wrong. My contention is that if you take the fail fast philosophy to its extreme (which is probably ill-advised), you must find static, compile-time type checking to be the best approach (since that is about as early in the process as you can get), and you will have to abandon dynamically typed languages altogether.

Example (obviously contrived):
someMethod(); ?>

This is perfectly legal PHP code, yet it will fail at runtime about half the time. With static typing, the language would “know” that an error exists, and would refuse to compile it. However, dynamically typed languages would accept the equivalent of the above code without any complaints. Hence, they are not “failing fast”.

However, clearly dynamically typed languages have some (or many, depending on whom you ask) advantages over statically typed ones in certain contexts. My only point is that sometimes other concerns take priority over failing as fast as possible.

It *is* about undiscovered errors in the sense that although continuing after an error is in some cases desireable, the rule and not the exception is that it’s best not to do so.

But in any case it should be a deliberate decision to let the program continue, not the default behavior of the language. The last thing you want is to believe everything is fine meanwhile your data is quietly getting corrupted as the program continues. Halting the program is one obvious way to prevent that.

I believe a language should trust the programmer to know when to catch an error and when to let it pass. But to do that, the programmer must at least be given the decision first.

From The Zen of Python:

Errors should never pass silently.
Unless explicitly silenced.

If an error is consistent in its behavior and causes, then it’s easier to find and fix, and you can be more confident your code isn’t a mess. It’s just a simple bug.

If an error is sporadic and there seems to be little rhyme or reason to its causes and effects, the bug is harder to fix. It’s also a reason to start wondering if there aren’t many other subtle problems with your code.

Just my two cents.