Re: Regarding exception handling

From: Bryan (belred_at_gmail.com)
Date: 01/31/05 

To: python-list@python.org
Date: Sun, 30 Jan 2005 22:53:40 -0800

Dan Perl wrote:
> "Bryan" <belred@gmail.com> wrote in message
> news:mailman.1614.1107137827.22381.python-list@python.org...
>
>>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.
>
>
> But IMO, try-finally is meant to be used only if the block in the try clause
> may raise exceptions. Here is an example that shows what I meant:
> s = ... # socket opens
> try:
> a = 1
> finally:
> s.close()
>
> works perfectly the same as:
> s = ... # socket opens
> a = 1
> s.close()
>

the above is not the same. make the a = ... raise an exception and you'll see
the difference.

s = ... #
a = 1/0
s.close()

as you can see, s.close() will never be called. also, in this example, i
intentionally didn't put the extra try/except around the try/finally statement.
    usually i let an exception caused by s = ... to bubble up to some level that
knows how to handle that error. we are talking about a resource here and in my
experience, these low level functions (below the UI or management layer) don't
know how to or shouldn't handle resources that can't be opened.

bryan

> The try-finally statement does not "handle" the exception, but it makes
> sense only if exceptions are possible. There is no point in enclosing "a =
> 1" in any kind of try statement.
>
> According to a following posting from Angelos he did expect some other
> exceptions than socket.error and hence the nested try's. To my defence
> though, I put in a disclaimer for that case in my initial posting.
>
>
>>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.
>
>
> That is a very good point. I missed it.
>
> Dan
>
>

Relevant Pages

  • Re: Exceptions and out procedure arguments (using GNAT GPL)
    ... raise My_Exception; ... and has an exception handler ... you can count on any assignments that you've already done ... The sample is a highly condensed version of my Query procedure ...
    (comp.lang.ada)
  • Re: contracted exceptions
    ... silently dies -- without notifying anyone. ... Enforcing the subprograms ... superior to the existing rule of silently ignoring the exception. ... Or raise Program_Error in the parent task at the point where that task ...
    (comp.lang.ada)
  • Re: ascii to tword - help
    ... if(cmp128(inputL, ... Raise($1_1285); ... we succeeded if we got this exception. ...
    (alt.lang.asm)
  • C++ Design Principles for Ruby - Prefer Abstract Interfaces.
    ... raise "Pure virtual" end end ... class TypeCheckException < Exception ... class DuckTypingException < TypeCheckException ... class PolymorphicTypeException < TypeCheckException ...
    (comp.lang.ruby)
  • Re: AssignFile, Reset und IOResult 103
    ... on exception do ... Raise ESecHashException.Create('File not found! ... Raise ESecHashException.CreateFmt('Could not open File ''%s''.'#13#13' ... Die beiden Dateinamen haben definitiv nichts miteinander zu tun. ...
    (de.comp.lang.delphi.misc)