Re: Try-catch and try-finally

[Sean Conner <sean@...>]

It was thus said that the Great Alysson Cunha once stated:
> In my point of view, an exception is potentially what the name says: An
> Exception, something unusual and probably unexpected. Definitely (yet in
>  my point of view) it's a good design prepare your code for unexpected
> cases.
> 
> In a simple example of file transfer over the internet, unexpected things
> can occur in the middle of the process and it is a good pratice ensure that
> the "file handle" will be closed at the end no matter what. In these case,
> a try-finally statement would be very useful.

  A long time ago in college I was writing a program and wanted to log any
errors.  The context of the program was such that I could not assume that
any error message would be seen on the screen so instead I opted to log to a
file.  But as I was doing that, the thought came to mind, "What if the write
to disk call failed?"  So I then fell back to dumping the error to the
printer.  But then that too, could fail---there might not *be* a printer, it
it could be offline or otherwise not responsive.  I was at a loss of what to
do.

  So I asked one of my instructors [2] what to do.  His words, and I quote,
where:

	if you do not know how to handle an error, don't check for the eror.

  It horrified me at the time, but over the years, I can see thw wisdom in
that, and has led me to my preference for crashing hard and fast in the face
of difficult conditions.

> Probably we have different point of view of what is a good code design when
> facing exceptions and unexpected situations.

  I wrote about this several years ago
(http://boston.conman.org/2009/12/01.2) when I classified errors into four
types (in a more-or-less arbitrary order):

	1. programming errors, like EBADF (not an open file, or the
	operation couldn't be done given how the file was open originally)
	or EINVAL (invalid parameter) that need to be fixed, but once fixed,
	never happens again;

	2. it can be fixed, like EACCESS (bad privileges) or ELOOP (too many
	symbolic links when trying to resolve a filename) but that the fix
	has to happen outside the scope of the program, but once fixed,
	tends not happen again unless someone made a mistake;

	3. better exit the program as quickly and cleanly as possible
	because something bad, like ENOMEM (insuffient kernel memory) just
	happened and things are going bad quickly. Depending upon the
	circumstances, a fast, hard crash might be the best thing to do;

	4. and finally, the small category of errors that a program might
	be able to handle, like ENOENT (file doesn't exist) depending upon
	the context (it could then create the file, or ask the user for a
	different file, etc.).

  I tend to view exceptions as "really bad" like a divide-by-0 or a bus
error or some other catastrophic failure of the program or the computer, but
I am willing to conceed that it might be my background speaking (assembly
and C programming for most of my career).  

  Do keep in mind that an exception is a non-local GOTO.  In fact, it's
worse, it's a dynamic GOTO and it makes it harder to reason about a program.

  -spc

[1]	The program ran on a PC in the pre-network era, so the chances of
	another program using the printer wasn't much of a concern.

[2]	A twenty or thirty year veteran of IBM.