lua-users home
lua-l archive

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


Reuben Thomas wrote:
> 
> > Even with, I_M_HO these kind of non-local return paths are much too error
> > prone to be used as a generic programming tool.
> 
> Is there some reason why they're worse in Lua than in, say, Java or
> Modula-3?

I didn't say they are "worse" :-)

> There they are very handy for separating error-handling code from
> normal-case code,

Sure.  Very handy and tempting.  (But you may lose your soul ;-))

> and I've not heard anyone suggest before that they're
> error-prone; on the contrary, they encourage all errors to be handled,
> unlike in other languages, for example C, where programmers often balk at
> checking *every* return code, because it makes the resulting code so lengthy
> and ugly.

And IMHO here's the point: you have to consider every possible exception
the same as the error return codes of ie a C function.  But the exceptions
make you feel save (a la: will be handled by upper levels anyway) and you
become lazy.  Destructors for local variables make you even feel more secure.
At some point you do not even notice that some operations may raise except-
ions (think about overloaded operators in C++).

I gave an example from Lua's iolib:

	FILE *fp = fopen(...)
	if (fp) lua_pushusertag(L, fp, iotag);

That's such a case.  At some point you will forget that this function may
raise an exception (very seldom but possible).  With destructors (here for
fp) you're still save [1].  At some point you stop to consider possible
exceptions because everything seems to be handled so well and you get
caught by situations where destructors and upper handlers cannot help any
more.

Just look at Lua.  I would say it's made by very able programmers.  Afaics
they've caught every possible error passed back via "conventional" C error
notifications (NULL pointers et al).  Now browse the code and look for
places where exceptions could happen and leave something unhandled.  You'll
find a couple of these [2].  I_M_HO exceptions encourage you to forget
handling errors!

In languages like Lua where nearly every second character in your source
may generate an exception it becomes really difficult (i.e. "a=a+1" could
generate an exception for fetching a, one during the '+' and one while
storing a).  The exceptions become uncontrollable.  That's why I said
"Only use them if program termination or data corruption is acceptable." [3]

Ciao, ET.

PS: Maybe all this sounds a little bit paranoid.  But without this "para-
noid" view PI would probably be 3 ;-)  In real life a more pragmatic way
is often required and good enough (3.14159).


[1] unless you've just created a new file that keeps staying around...

[2] I only took a brief look but found three: one in dofile, one in the
iolib (both fd-leaks), and one in luaB_call (may leave _ERRORMESSAGE in
bad state).  I guess there are more.  When considering tinsert-like func-
tions it becomes even more ugly :-(

[3] One could question if you have to live with this in these kind of
high level languages and use exceptions everywhere.  Maybe that's one
of the reasons I still prefer simple (controllable) C over C++ and Co ;-)