Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!news.up.net!news.mtu.edu!newsxfer.itd.umich.edu!ncar!gatech!newsfeed.internetmci.com!howland.reston.ans.net!math.ohio-state.edu!newsfeed.acns.nwu.edu!ftpbox!mothost!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Fri, 29 Mar 1996 16:25:24 GMT
Message-ID: <1996Mar29.162524.28067@schbbs.mot.com>
References: <4je18p$lnr@dscomsa.desy.de>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 56
Xref: news.daimi.aau.dk comp.object:53434 comp.lang.eiffel:22588 comp.lang.c++:175722 comp.lang.beta:10696 comp.lang.java:29775 comp.lang.sather:12377


In article <4je18p$lnr@dscomsa.desy.de> mernst@x4u2.desy.de (Matthias Ernst)  
writes:
> I also agree but have some problem about the way the exception handler
> passes back information to the 'thrower'. Or, the other way around, how can
> the 'thrower' ask for dedicated information in an anonymous outer frame
> (a la 'Do you really not want to save your changes ?')
> 
> I fear, for retry-semantics the handler is too near to the thrower, too deep
> in the hierarchy to provide this information.
> 
> try
>   font = getfont(name, size)
> except exc: FontNotAvailable
>   ask_for_new_font(out name, out size)
>   -- Ask the user here ? We're deep in the functional part, 
>      not aware of our user interface
>   retry
> end;
> 
> With resumption-semantics the handler might alter the exception object:
> 
> try
>   init_interface -- which is a deep hierarchy
> except exc: FontNotAvailable
>   ask_for_new_font(out name, out size)
>   exc.new_font_name = name
>   exc.new_font_size = size
>   resume
> end;
> 

Good examples. I am not sure whether it is pratically sufficient
if we just provide one-level correspondence between caller and callee
on the retry-semantics base. For example, initialize interface is usually
done in the application develoipers and they should know how to deal
with exceptions like font is not found.

If deep levels are involved, resumption-semantics may be helpful to
avoid to re-initialize the whole interface. But we perhaps can
have a retry on the smallest try cloure where the exception is thrown,
rather than a resumption exactly from the point the exception is trown.

> But I fear that at the toplevel all the handlers for missing information
> accumulate to a great mess.

I agree that to handle deep level resumption/retry is very complicated, and
it seems that there were no neat solution.

In my personal experience with a number of user interface designs, I've
been happy with just one-level correspondence between callers and callees.

David Shang