Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!columba.udac.uu.se!news.mdh.se!news.seinf.abb.se!erinews.ericsson.se!eua.ericsson.se!cnn.exu.ericsson.se!newshost.convex.com!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!surfnet.nl!swsbe6.switch.ch!scsing.switch.ch!news.dfn.de!news.dkrz.de!dscomsa.desy.de!x4u2!mernst
From: mernst@x4u2.desy.de (Matthias Ernst)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Followup-To: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Date: 28 Mar 1996 12:38:49 GMT
Organization: DESY
Lines: 77
Message-ID: <4je18p$lnr@dscomsa.desy.de>
References: <4j948d$t3d@trumpet.uni-mannheim.de> <1996Mar27.134800.18605@schbbs.mot.com>
NNTP-Posting-Host: x4u2.desy.de
X-Newsreader: TIN [version 1.2 PL2]
Xref: news.daimi.aau.dk comp.object:53431 comp.lang.eiffel:22587 comp.lang.c++:175716 comp.lang.beta:10695 comp.lang.java:29765 comp.lang.sather:12376

David L. Shang (shang@corp.mot.com) wrote:
: In article <4j948d$t3d@trumpet.uni-mannheim.de> mw@ipx2.rz.uni-mannheim.de  
: (Marc Wachowitz) writes:
: > David L. Shang (shang@corp.mot.com) wrote:
: > > But an exception is not necessarily an error. Sometimes it is an
: > > condition that requires some extraordinary computation, a condition
: > > that is not supposed for a regular case, [...]
: > 
: > Let's look at the problem with fresh eyes, without thinking immediately
: > about using the technical feature called "exception" in a few programming
: > languages.
: > 
: > Some routine (often supposed to be reused for different contexts) wants
: > the "advice" of its caller (or the caller's caller etc.) how to handle an
: > unusual condition ("advice" might imply activities, like a user query).
: > 

: Couldn't agree more. That is what an exception handling is supposed to
: do, and that is the case where exception handling is helpful. Back to
: my original post, I analyzed two cases for exception handling:

: * the callee decides how to handle the exception; and
: * the caller decides how to handle the exception;

: And I concluded that the second case is more important and useful.

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;

and somewhere in the hierarchy the thrower may try with the new font name.

while not_available(name, size)
  exc = new FontNotAvailable(name, size)
  throw exc -- exc will be filled out with new font information
  name = exc.new_font_name
  size = exc.new_font_size
end -- while




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

Anyway termination semantics don't help further.
   
Solutions, anyone ?

-- Matthias