Re: Exception handling (was Re: ...add to Lua...)

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> Op Ma., 17 Sep. 2018 om 00:08 het Sean Conner <sean@conman.org> geskryf:
> >
> > It was thus said that the Great Sean Conner once stated:
> > >
> > > [2]   Personally, I don't think exceptions should exist as a concept in
> >                                                    ^NOT


> > >       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).
> >
> >   Oops.
> 
> That single ^NOT, appearing in a non-monospaced font, correcting a
> sentence starting "Personally" (which usually means that, in the
> opinion of the author, a non-PC point of view will follow) makes it
> totally impossible to figure out what you are trying to convey.

  I messed that up (I can't read today---it was fine as it was originally).

  Basically, exceptions should not exist as a concept in user code.  This
gets into error handling in general.  There only exists two ways to handle
errors:

	1) it is handled by the routine itself
	2) it is passed off to another routine

  Going into further detail:

	1) it is handled by the routine itself
	  a) no check is performed at all [5]
	  b) the error condition is noticed but ignored

	2) it is passed off to another routine
	  a) by passing an error indication to the caller
	  b) by calling code to handle the error

Exceptions fall under 2b) calling code to handle the error.  Yes, I contend
that most (if not all) exceptions are (expensive) calls to some other piece
of code.  If it's a hardware exception (like a segfault or divide-by-0) it's
an expensive call into the kernel; for a C++ or Java like exception, it's
probably to code that walks back up the call chain looking for a suitable
handler, possibly calling destructors (if in C++) along the way.  

  The main reason I dislike exceptions is they are overused (much like OOP
is overused [6]).  Furthermore, they are a form of dynamic GOTO (via that
expensive call) that makes it very hard to figure out flow control.  You had
Java with checked exceptions, but that made code exceedingly tedious to
program so everybody derived from the one non-checked exception
available---RunTimeException.  C++ never did the checked exceptions (so
there's that) but you still have issue with where did the execution go?

  Now, on to your questions ...

> Do you basically agree that
> 
> (a) languages usually run from an interpreter or a host program (as
> Lua is) should offer (as Lua does) three abnormal exits from a
> program:

  What do you mean by "program?" [8]

> (i) to the previous level of execution [1]

  So here "program" is "function"?

> (ii) to the host [2]

  What do you mean by "host?"  Because my definition is the same as
"system", which you list below.

> (iii) to the system [3]
> 
> (b) that the previous level should be allowed to intercept an exit to
> the host [4]
> 
> c) that this degree of flexibilty is in fact quite rare in other
> languages, even (if not especially) those with "try..except"
> mechaniisms?

  There's LISP, which goes even futher with conditions.

> -- Dirk
> 
> [1] In Lua, by way of type and number of return values, especially
> "false, message"'
> [2] In Lua, by way of error())
> [3] In Lua, by way of os.exit()
> [4] In Lua, by way of pcall()

  I'm not sure I follow you line of thought here.  (i) is your typical

		if some_error_condition then
		  return some_error_indication
		end

  Your (ii) and (b) are two sides of the same coin, as pcall() can
"intercept" error() (basically, pcall() is a catch to error()'s throw).  But
my main thrust against exceptions is really your case (b)---if you catch a
Lua syntax error via pcall(), what can you realistically do in that case [9]? 
Not much---it requires user intervention to fix the error.  The same for
trying to divide by 0, or anything else that causes Lua to abort execution
of Lua code.

  So I'm having a hard time agreeing or disagreeing with your statement.

  -spc (If it helps, I'm in the "fail fast" category of programmer ... )

[5]	Back in college, I found myself with a problem where I could not
	figure out how to handle an error condition---the screen won't be
	seen, the disk is full, and the printer is off-line, how do you
	report the error?  I asked one of the professors who answer---"If
	you don't know how to handle the error, don't check for it." I was
	horrified by the answer, but time has shown he was correct.

[6]	Alan Kay is upset at us (as an industry) for failing to read his
	mind with respect to object oriented programming.  He didn't
	actually mean objects ala C++ or Java, but small simple programs
	that process messages handed to them.

	To be fair to us, he didn't explain himself very well when Smalltalk
	was released and we ended up with a generation of programmers trying
	to figure out if a square is a subclass of a vehicle or is the
	vehicle a subclass of a mammal [7].

	The followup generation now talk about dependency factory factories
	and raviola code---the OOP version of spaghetti code.

[7]	A joke.  Most OOP is taught using shapes, vehicles or animals.  All
	horrible examples for OOP.

[8]	I have a definition in mind, but it might not be your definition.

[9]	I wrote about it a bit here:

		http://boston.conman.org/2009/12/01.2

	(near the bottom)---I classified four categories for errors, along
	with three ways of handling them, but I've thought hard about that
	since then and modified my position somewhat (two two ways of
	handling errors).