Re: new thought experiment: what would you add to Lua ?

[Sean Conner <sean@...>]

It was thus said that the Great Alysson Cunha once stated:
> That "fake" piece of code is so ugly, which makes difficult to others
> programmers understand your code.

  It seems pretty understandable to me, but then I'm not a fan of OOP.

  At work, I have to work with code that was described by its programmer as
"boring, plain, straightforward code that uses no tricks." I can't
understand it *at all*.  And of course, the reverse is true---my boring,
plain, straightforward code that uses no tricks is very hard for the other
programmer to understand.

> Besides, it does not handle "finally" correctly because, in case of
> "finally  execution due error, the error must be raised again

  Different langauges handle exceptions differently.  Java requires checked
exceptions (a function must declare it throws an exception, even if it
doesn't do so directly [1]) where as C++ does not.  If you are used to
checked excpetions, then C++ (and even this Lua example) would not work for
you.

  I am also not a fan of exceptions as currently implemented in every
language [2].

  -spc (That's not to say I haven't used exception-like stuff, but only
	in very certain situations [4]).

[1]	Which I found extremely annoying.  I can understand the rational for
	it but that doesn't mean it's a good idea.

[2]	Personally, I don't think exceptions should exist as a concept in
	user code at all.  If a program reeives a seg fault (a perfect
	example of an exception) then the program is borked---is is trying
	to reference memory that is not mapped into its memory space and
	trying to recover might not be the best approach (or even possible,
	depending upon where it happened).

	Other possible exceptional events, like division by 0, invalid
	opcode, memory error [3], likewise means the program is operating
	incorrectly and any attempts for the program to save itself (or
	ignore the error) is in vain.

	Errors that are usually signaled via exceptions (out of bounds,
	can't open a file, network connection dropped, window changed size,
	etc) are a normal occurance and may or may not indicate an error
	(out of bounds, if unexpected, yes---perhaps the code was probing in
	which case, no; can't open a file, maybe it doesn't exist and that's
	okay at that point in time).

	I know I'm probably in the minority with this viewpoint.

[3]	The original IBM PC mapped memory errors to the NMI line and would
	basically stop all processing entirely, in the ground that if memory
	is corrupt, there's is no point in going any further---even the OS
	might be borked.

[4]	Parsing text.  I have found it much nicer to just skip back to the
	top of the main parsing loop instead of trying to bubble up errors
	through the call stack.  But in this case, it's not an "exception"
	but more of a "controlled jump back to where I can return an error
	to the calling code".  Why not propagate the "exception" back to the
	calling code?  It depends upon the language and how complex (or
	nasty) the code would be to catch the controlled jump.