Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Monday, Oct 20, 2003, at 03:21 US/Pacific, Robert Collins wrote:

> Oh, and as for exceptions being 'all that' ? Exceptions don't prevent
> bad state in objects, they don't prevent bugs, all they do is ensure
> that cleanup routines have a chance at trapping abnormal events within
> the same process.

	I don't think this is quite accurate.  Exceptions allow you to 
separate error handling from programming logic.  Consider the following 
pseudo-code:

        open(file);
        readFrom(file);
        close(file);
        open(file2);
        writeTo(file2, "Did some stuff\n");
        close(file2);

	In languages that do not raise exceptions normally upon error, you 
have to check the results of each of those calls to make sure they're 
successful, as well as figuring out something to do when they're not.  
These are two things that put extra burden on a programmer that is 
often skipped because it's additional work that is not directly related 
to the logic that the programmer wants expressed.

	Exceptions are more about doing the right things with less work.  
Given two languages, one that generally throws exceptions in 
open/read/write (python) and one that does not (perl), consider the 
consequences.  I would have to add code to the perl version (ignore 
Fatal for now, I think that's a fairly stupid hack) in order to remove 
bugs (i.e. if you can't read from the first file, don't write to the 
second).  I would have to add code to the python version in order to 
get it to write to the second file even when it is unable to read from 
the first.

	To me, this means one of two things (or both) is likely to happen when 
using languages without exceptions.  a)  Certain elements of error 
checking is not handled.  b)  Certain pieces of an application take 
longer to implement because you have to spend more time dealing with 
error conditions than you normally would.

	Hackerlab actually does a pretty good job of making things easier 
without introducing bugs, but the current implementation of panic() 
doesn't allow for much flexibility (for example, the second python 
scenario above, something has failed, but I still want to log).

--
Dustin Sallings