Re: Try-catch and try-finally

[Sean Conner <sean@...>]

It was thus said that the Great Alysson Cunha once stated:
> I am proposing a language sugar =)
> 
> Because It's not a simple matter of the file exists or not.
> 
> Think about these 3 real case examples:
> - A not gracefully end of the tcp connection can occur.
> - if the file is stored in a Pen Drive, the user can unplug the device in
> the middle of the process or a bad contact in the wires can lead to
> physical IO errors.
> - If the user is connected via an USB Wireless adapter, if the user unplugs
> the device or a bad contact in the wires occur, physical IO errors can
> occur.
> 
> Many other unexpected situations can occur.

  Sure.  How do you handle them?  It really depends upon the context.  If
it's a one-shot program, probably exiting the program with an error message
might be good enough.  For a long running daemon:

	- I would expect abrupt end of connections as normal and handle it
	as I would, say, garbage being sent in.

	- A drive disappearing from beneath me is way out of the range of
	what the program should expect (and in this case, I'm talking about
	a long running daemon process) so a quick, hard and very loud crash
	is fine---it would alert the operators that something Really Bad(TM)
	is happening.  I might even do this if a write to a file failed,
	because again, something Really Bad(TM) is happening (a volume
	filled up).

	- Again, this is something beyond the program's baliwick.

  How would you handle it?  Okay, you throw an exception ... now what?

  There are three ways of dealing with these [1]:

	1. every subroutine returns an indication of success or failure (C
	uses this—the “calls filter downward, errors bubble upwards” model)
	and every call site needs a check;

	2. subroutines can cause an exception, which immediately transfers
	program flow control to some earlier caller up the stack frame,
	which caller gets the exception depends upon which caller is
	expecting which exception (C++ uses this—the “dynamic spaghettiesque
	come-from” model);

	3. ignore errors entirely and assume everything will always work
	(you can do this in any programming language—it's from the Alfred E.
	Neuman “What?  Me, worry?” school of programming).

  Each have their pros and cons.

  -spc (Not a fan of exceptions)

[1]	http://boston.conman.org/2009/12/01.2