Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Monday, Oct 20, 2003, at 19:27 US/Pacific, Tom Lord wrote:

> As the part of thread between me and Walters illustrates, it takes a
> lot of work to employ exceptions without screwing up abstraction
> barriers.
>
> As reams and reams of unix code, not to mention tla, illustrates:  you
> can write quite useful tools without the hassle of exceptions.

	Yes, as I stated, the work has to be done somewhere.  Hackerlib does a 
pretty good job here and would just need a more 
persistent-application-friendly implementation of panic().  It seems 
ideal for the way tla is implemented.

> We haven't talked about it but a big problem with exceptions is that
> they tend to drive people towards wanting "exception classes" -- but
> in general purpose libraries or complex applications there's (for deep
> reasons) no one "class hierarchy" that Does The Right Thing.

	Nothing makes this point more painfully obvious than python's horrible 
db abstraction layer.  Exception classes are documented, but you can't 
actually catch them because they have no common root in practice, just 
a naming convention.

> Have you noticed that calls in tla are to `safe_printfmt'?

	Yes, but this goes to my point.  You [I know I'll get beat up for this 
one] changed the language to make it easier to develop more reliable 
code.  Users who ignore the result of printf are ignoring errors.  
safe_printfmt removes your eligibility for that category.

> What are going to be options (3) and (4)?:
>
> 3) "Higher level code" catches an exception from a deeply nested call
>    to printfmt and tries to Do The Right Thing.    Congratulations,
>    you have written spaghetti-code by violating abstraction violations
>    left and right.

	I work on mediumish systems (970 classes, 140k LoC, however you want 
to size it) that have to consider these types of details.  It's not 
much different.  When I invoke tla to perform a task, it will succeed 
or fail and provide me an indication of what went wrong.  This is the 
basic contract for any UNIX application.  Is it an abstraction 
violation that I get a panic about reading/writing a file somewhere 
under {arch} to stderr?  I don't really see this as being any different.

	Your API defines an exception type it will raise if there's a problem. 
 If it has an issue performing its task, no matter what the reason, it 
will raise this type of exception.  Where exceptions can be chained, 
all is well.  If exceptions can't be chained, then you're pretty much 
where you are without them.

> 4) Your program is tossed into the debugger.   You fix stuff and tell
>    the debugger to continue.   Congratulations, you are using a good
>    lisp system.

	Heh, this type of system isn't always good, either.  I've got a 
smalltalk based web server.  If it goes wrong and jumps into the 
debugger, I'm not even sure I'd know.

> > Especially java?  All of the core java stuff throws exceptions when
> > there's an error (I'm sure there's at least one exception
> > somewhere).
>
> *cough<talkingouthisass>cough cough*
>
> As long as your _sure_ then we're all glad to hear what you have to
> say :-)

	Well, that was phrased a little poorly.  The second ``exception'' in 
there was referring to an exception to the rule of the core stuff 
throwing exceptions.  I meant to add it as a loophole in case someone 
came back with one example that was done differently (I thought I'd 
seen one before, but couldn't remember where).

	It's a matter of perspective, though.  The java.util.Map interface 
states that get(Object) will return null if there is no matching 
object.  Should it be an exception?  Python says yes, java says no.

>   1) No, exceptions aren't quite the panacea you may have heard.

	This sentence seems to imply that I'm new to programming.  Please 
don't assume that this is the case.

	I entered this thread because someone had suggested that exceptions 
are only useful for introducing cleanup code.  I believe this to be 
false and stated why I think so.

	The largest part of this argument was regarding my opinion of perl's 
Fatal module to be a stupid hack.  As I stated (and I believe you wrote 
something to the effect as well), it's more harmful to have 
inconsistent error handling styles than it is to have one that you 
consider better (whichever that may be).

	I program in various languages, some use exceptions as The way to 
handle errors, some provide exceptions, but don't do too much with them 
(objc is kind of weird like that), some offer ways to implement 
exceptions (scheme, C), and some don't even have a way to implement 
them.  I've written plenty of quality software each way.

>   Goal: write mkdir(1)
>
>   Question: Are exceptions going to help you?

	I understand your point here, but yeah, they will and here's why 
(print added for effect):

        perl implementation:

mkdir($ARGV[0]);
print "Successfully made $ARGV[0]!\n";

Results:
desktop:/tmp 3031> ./mkdir.pl /makeme
Successfully made /makeme!
(exit code 0)
desktop:/tmp 3032> ls -l /makeme
ls: /makeme: No such file or directory

        python implementation:

os.mkdir(sys.argv[1])
print "Successfully made", sys.argv[1]

Results:
desktop:/tmp 3034> ./mkdir.py /makeme
Traceback (most recent call last):
  File "./mkdir.py", line 6, in ?
    os.mkdir(sys.argv[1])
OSError: [Errno 13] Permission denied: '/makeme'
(exit code 1)


	...minus the -m and -p options and the loop, the python version is so 
for compliant with my mkdir(1) man page.  The looping is trivial, but 
the results from both -m and the recursive call to implement -p would 
also require IO error checking and propagate that up the stack or 
exit() with an appropriate value.  My preference would be to send it up 
the stack because I've had too many reusability problems with code that 
caused a process termination for stupid things, but that would be a 
great deal more complicated.

	But seriously, this isn't my argument.  I'm just saying that in a 
language that uses them consistently, exceptions are good and make it 
easier to write code that works reliably for people like me who'd 
rather spend their time worrying about the One True Path and less time 
worrying about every possible error condition.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <address@hidden>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________