Exception scope and handling

Exception scope and handling

[Sandro Binetti]

 There's something that's not clear, or, better, I can't understand
about exception scope and handling.

Suppose to declarate an exception inside the declarative region of a
procedure, and handle it at the end of the body of the procedure.
What's the meaning of re-raising this exception outside this body?

Take a simple example:

procedure PROC1 is

  procedure PROC2 is
    FOO:EXCEPTION;
  begin
    ....
    ....
  EXCEPTION
    when FOO => handle_it;
                raise; -- ???? what's the meaning of this
  end proc2;

begin
  ...
  ...
  ...
  -- what kind of object is FOO here?
EXCEPTION
  when others => -- ???? why coul'd I handle FOO here, even if I don't
                 -- know anything about it?
end proc1;

--
Ciao, Sandro


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exception scope and handling

[des walker]

Sandro Binetti wrote:

>  There's something that's not clear, or, better, I can't understand
> about exception scope and handling.
>
> Suppose to declarate an exception inside the declarative region of a
> procedure, and handle it at the end of the body of the procedure.
> What's the meaning of re-raising this exception outside this body?
>
> Take a simple example:
>
> procedure PROC1 is
>
>   procedure PROC2 is
>     FOO:EXCEPTION;
>   begin
>     ....
>     ....
>   EXCEPTION
>     when FOO => handle_it;
>                 raise; -- ???? what's the meaning of this
>   end proc2;
>
> begin
>   ...
>   ...
>   ...
>   -- what kind of object is FOO here?
> EXCEPTION
>   when others => -- ???? why coul'd I handle FOO here, even if I don't
>                  -- know anything about it?
> end proc1;
>
> --
> Ciao, Sandro
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Hi Sandro,

  according to my copy of Programming in Ada (Barnes) what you show here
is valid - the exception can be handled outside of its scope. by using the
'others' clause.

This is because exceptions can be thought of as existing throughout the
life of the program rather than existing dynamically only when you hit the
declaration at runtime.

Barnes goes on to show that an exception can be propogated out of scope
and then back into scope as it is passed up the calling chain. viz:

package Odd_Exception is
  procedure A;
end Odd_Exception;

package body Odd_Exception is

  I : Integer := 10;

  procedure B is
  begin
    A;
  exception
    when others => raise;
  end B;

  procedure A is
    At_Zero : exception;
  begin
    I := I-1;
    if I > 0 then
      B;
    else
      raise At_Zero;
    end if;
  exception
    when At_Zero =>
       Text_Io.Put_Line("detected At_Zero exception");
       raise;
  end A;

end Odd_Exception;

naturally this is not a very useful example! But if the procedure A is
invoked it will call procedure B, which in turn calls procedure A, 9 times
before the At_Zero exception is raised. The exception is propogated
through each call of procedure B and procedure A. It is handled by name in
each call of procedure A so that the text will be output 10 times (even
though the exception was not in scope when reraised in procedure B).

I have no idea what use you could actually find for this feature, but
maybe others will know :-)

Regards
    Des Walker
    Alenia-Marconi Systems

Re: Exception scope and handling

[Robert Dewar]

In article <3A0FCD45.269A379F@bton.ac.uk>,
  John English <je@bton.ac.uk> wrote:
> The exception propagates out of proc2 and is caught by the
> exception handler in proc1, but the name FOO ceased to exist.

Well this is a little misleading, the comment from Des is a
bit clearer here. Exceptions are not like variables. When you
leave the scope of a procedure, a local variable is really
really gone.

But exceptions are global objects, unlike a variable in the
recursive case, where there is one variable for each level,
in the case of an exception declared in a recursive procedure,
there is only one for all levels (it's a bit similar to an
"own" variable in Algol-60, or a static variable in C).

So when you leave the procedure, the name temporarily goes
out of scope, but for example, if the caller gets the exception
occurrence, stashes it away, and later calls the original
procedure passing in this exception occurrence, then the
exception can be handled by name even without needing
recursion.

Yes, you can't handle it by name if it's not visible at the
point of the caller, but that's just a normal visibility rule.



on exit from proc2,
> so when you catch it in proc1's exception handler you can no

longer
> refer to it by name (so you can't say "when FOO", you have to

say
> "when others"). The fact that an exception's name may be lost

to
> view doesn't mean that an active instance of the exception

itself
> will go away when the name does -- exceptions don't go away

until
> they're caught and handled.
>
> It's usually a good idea NOT to declare exceptions in nested

scopes
> for this very reason.
>
> HTH,
>
>

----------------------------------------------------------------

-
>  John English              | mailto:je@brighton.ac.uk
>  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
>  Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS

**
>  University of Brighton    |    -- see http://burks.bton.ac.uk
>

----------------------------------------------------------------

-
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exception scope and handling

[John English]

Sandro Binetti wrote:
> Suppose to declarate an exception inside the declarative region of a
> procedure, and handle it at the end of the body of the procedure.
> What's the meaning of re-raising this exception outside this body?
> 
> Take a simple example:
> 
> procedure PROC1 is
> 
>   procedure PROC2 is
>     FOO:EXCEPTION;
>   begin
>     ....
>     ....
>   EXCEPTION
>     when FOO => handle_it;
>                 raise; -- ???? what's the meaning of this
>   end proc2;
> 
> begin
>   ...
>   ...
>   ...
>   -- what kind of object is FOO here?
> EXCEPTION
>   when others => -- ???? why coul'd I handle FOO here, even if I don't
>                  -- know anything about it?
> end proc1;

"Raise" on its own re-raises the same exception (FOO in this case).
The exception propagates out of proc2 and is caught by the exception
handler in proc1, but the name FOO ceased to exist on exit from proc2,
so when you catch it in proc1's exception handler you can no longer
refer to it by name (so you can't say "when FOO", you have to say
"when others"). The fact that an exception's name may be lost to
view doesn't mean that an active instance of the exception itself
will go away when the name does -- exceptions don't go away until
they're caught and handled.

It's usually a good idea NOT to declare exceptions in nested scopes
for this very reason.

HTH,

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------