* Exception scope and handling @ 2000-11-13 0:00 Sandro Binetti 2000-11-13 0:00 ` John English 2000-11-13 0:00 ` des walker 0 siblings, 2 replies; 4+ messages in thread From: Sandro Binetti @ 2000-11-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Exception scope and handling 2000-11-13 0:00 Exception scope and handling Sandro Binetti @ 2000-11-13 0:00 ` John English 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` des walker 1 sibling, 1 reply; 4+ messages in thread From: John English @ 2000-11-13 0:00 UTC (permalink / raw) 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 ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Exception scope and handling 2000-11-13 0:00 ` John English @ 2000-11-13 0:00 ` Robert Dewar 0 siblings, 0 replies; 4+ messages in thread From: Robert Dewar @ 2000-11-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Exception scope and handling 2000-11-13 0:00 Exception scope and handling Sandro Binetti 2000-11-13 0:00 ` John English @ 2000-11-13 0:00 ` des walker 1 sibling, 0 replies; 4+ messages in thread From: des walker @ 2000-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-11-13 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-13 0:00 Exception scope and handling Sandro Binetti 2000-11-13 0:00 ` John English 2000-11-13 0:00 ` Robert Dewar 2000-11-13 0:00 ` des walker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox