Regarding exception handling

Bryan belred at gmail.com
Sun Jan 30 21:18:57 EST 2005


Dan Perl wrote:
> "Aggelos I. Orfanakos" <aorfanakos at gmail.com> wrote in message 
> news:1107127179.863445.55310 at c13g2000cwb.googlegroups.com...
> 
>>Thanks. This should now be OK:
>>
>>#try:
>>#    try:
>>#        s = ... # socket opens
>>#
>>#        # various code ...
>>#    except socket.error, x:
>>#        # exception handling
>>#finally:
>>#    s.close() # socket closes
>>
> 
> 
> Why the nested try's?  If I understand your intention correctly this should 
> do the same thing:
> 
> try:
>      s = ... # socket opens
>      # various code ...
> except socket.error, x:
>      # exception handling
> s.close() # socket closes
> 
> You would need the try-finally statement only if you expect it to handle 
> other exceptions than socket.error or if the socket.error is re-raised in 
> the "except" clause.  Otherwise, the try-finally statement is redundant 
> because no socket.error are getting out of the try-except statement.
> 
> Dan 
> 
> 

i always use the try/finally statement with resources, but in a slightly 
different way than the above two examples:

s = ... # socket opens
try:
     # various code ...
finally:
     s.close()


or, if i want to handle the socket.error if s gets successfully bound,


s = ... # socket opens
try:
     try:
         # various code
     except socket.error e:
         # exception handling
finally:
	s.close()

i disagree with the statement:

"You would need the try-finally statement only if you expect it to handle other 
exceptions than socket.error or if the socket.error is re-raised in the "except" 
clause.  Otherwise, the try-finally statement is redundant because no 
socket.error are getting out of the try-except statement."

IMO, that is not the reason for the try/finally statement and it is not 
redundant.  the try/finally statement guarantees the resource is closed and the 
try/finally statement only gets executed if and only if the opening of the 
resource doesn't raise an exception.  it has nothing to do with exception handling.

in the previous 2 examples s = ... was placed inside the try/finally, but if an 
exception occures and s doesn't get bound to an object, then s.close() in both 
examples will raise a NameError on s.

bryan




More information about the Python-list mailing list