File handling: The easy and the hard way

[Jeremy Jones]

In order to beat an already dead and decaying horse:

Hans-Joachim Widmaier wrote:

>Am Thu, 30 Sep 2004 11:15:32 -0400 schrieb Jeremy Jones:
>
>  
>
>>>Tracebacks
>>>are fine for programmers, but end users really never should see any.
>>> 
>>>
>>>      
>>>
>>Bushwa.  End users may or may not be able to make sense of them, but it 
>>doesn't mean they _should_ never see them.
>>    
>>
>
>I see tracebacks as programmer errors. Now, a missing file isn't a
>programmer error, but not handling it gracefully is.
>  
>
Agreed (pretty much).  But "gracefully" is a relative term and may be 
different in different situations.  My point has been, sometimes the 
most graceful thing you can do is just let the exception bubble up to 
the top.  Should programmers try to handle as many exceptions as 
possible and keep the user from seeing them?  Absolutely.  Does that 
mean that it makes sense to always keep the typical, average, 
(non-technical even) end user from ever seeing them?  I don't think so.  
I think it's OK in absolutely extreme situations.  It may be OK even in 
some non-extreme situations, but I'm not going to assert that without 
thinking about it and providing an example.  My point is to use common 
sense.  Don't have a universal rule that says, "No user must ever see a 
traceback."

>  
>
>>I think the traceback is perfectly understandable.  I think that even an
>>end-user would be able to comprehend that type of message.  Or, if you
>>get an IOError, is this not sufficient: IOError: [Errno 28] No space
>>left on device ?
>>    
>>
>
>To programmers, yes. Or rather, no, as I tried to explain: even my
>co-workers switch to 'your program crashed' mode when they're confronted
>with a traceback. They never read that final line that tells them that
>the sole problem was a typo on their part.
>  
>
Your co-workers may need some help in this regard.  Perhaps they need to 
spend some more time with the interactive interpreter.  I can't tell you 
how many exceptions I've seen at the interpreter because I've 
fat-fingered something.  If they spent more time with the interpreter, 
maybe they would cultivate a different mindset.  Who knows - maybe their 
mindset it correct and mine is wrong?

>  
>
>>Chances are, end users aren't going to be particulary concerned with
>>exceptions you log - unless they've got a problem that they can't figure
>>out.  And if they've got a problem they can't figure out, you'd be
>>better off giving them as much information as you can give them, or
>>they'll come to you for help.  And when they do come to you for help,
>>you'd better make sure you've given yourself the most informatino you
>>can to solve the problem.  So logging a traceback is a great idea IMHO.
>>Now, in areas where you're dead sure that an exception is nothing to be
>>concerned with, don't bother.  So, a good approach may be: handle the
>>specific exceptions that you know may occur, let other unexpected (or
>>expected in worst case scenarios) exceptions filter up to a higher
>>level, log them there, and if need be, terminate program execution.
>>    
>>
>
>I don't want to _log_ exceptions, I want to handle them in a meaningful
>way. Of course, if an end user gets a traceback because of a program
>error, I'm more than happy with the traceback. This was unforseen
>(otherwise I'd handled that).
>  
>
I think this is a good approach and what I have been suggesting.  Handle 
all the exceptions you can foresee and keep them from the user.  But let 
the rest come up to the user and log it so either they or you or both of 
you together can figure out what the problem is. 

>
>  
>
>>I dunno - something just doesn't feel right here.  I kinda feel like
>>you're wanting to create an over-generalized solution.
>>    
>>
>
>Yes, that's bugging me, too. I'm not all that happy with it myself,
>otherwise I'd started to write such a class in the meantime.
>  
>
I think you are on track for writing a useful utility for certain types 
of file handling - not all types.  I would certainly not be happy if 
such a class replaced the standard file class.  I would not, however,  
be unhappy if such a thing made its way into the standard library as an 
exception handling file class with callback capabilities. 

>  
>
>>Hope I didn't jump too hard.
>>    
>>
>
>I can take it.
>
>Thanks for the good advice,
>Hans-Joachim
>  
>
As I mentioned to Steve in an earlier discussion on this same thread, I 
think that we're all saying a lot of the same things in different ways.  
I do apologize to you if I jumped on you a bit hard.  It appeared that 
you were asserting that this was the "proper" way of doing all file 
handling.  I don't think it is.  And I'm not sure you're saying that.  
Having said all that, I think I'm done with this thread. 

now-that-the-dead-horse-has-been-beaten-again-I-can-shut-up-ly y'rs,

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20041005/aee5f00a/attachment.html>