[e-lang] Remaining semantic issues

Karp, Alan H alan.karp at hp.com
Wed Jun 1 13:05:11 EDT 2005


Mark Miller wrote:
> 
> I think this is a terribly important question. My general experience 
> is that API designers go to a lot of trouble to distinguish different 
> error cases, so callers could dispatch on them, but that callers 
> invariably do something like
> 
>      if (read(...) < 0) {
>          perror(...)
>          // react to a failure to read
>      }
> 
I've been going through the Client Utility source code looking for
examples.  (I didn't write it, so it contains code produced by normal
programmers.)  While the above is a common pattern, I see others.  For
example, a given method may know how to deal with certain kinds of
exceptions but leaves others for methods higher up the call chain.
Another case is when certain types of exceptions can be ignored, but
others need to be dealt with.  I also found cases where different types
of exceptions were handled differently.  Here's an example

         while (true) {   
            try {
                rtn_fe = target_frame.resolve(temporary_name, 
		           arb_policy, new ExplicitEvaluationPolicy(),
null);
            } catch (TranslationInterrupt e0) {
                LookupContainer lc = e0.getLookupContainer();
                if (lc == null)
                    return null;
                temporary_name = new CUName(null, target_frame,
                             new
LogicalName(NameGenerator.genString())); 
                rtn_fe = target_frame.bind(temporary_name, lc);
                continue;
            } catch (CUInterruptedException e1) {
                rtn_fe = e1.getTargetResource();
                if (rtn_fe == null) {
                    return null; }
                temporary_name = rtn_fe.GetAccessorName();
                continue;
            } catch (CUCoreException e2) {
                rtn_fe = null;
                return rtn_fe;
            }
         } 

This code is trying to find a binding from a handle held by the process
to an entry in the process's clist.  I don't recall the details, but you
can see two different recovery attempts and one place where we gave up.
Why did we return null in the last case instead of throwing an
exception?  I have no idea, but I'm sure we had a good reason.  Note
that we expect the calling method to handle other exception types.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050601/49aba0bf/KarpAlanH.vcf


More information about the e-lang mailing list