[e-lang] Remaining semantic issues

Mark Miller markm at cs.jhu.edu
Thu Jun 2 10:45:06 EDT 2005


Karp, Alan H wrote:
> [...] I also found cases where different types
> of exceptions were handled differently.  Here's an example

I reformatted Alan's example so that I find it more readable. YMMV. In any
case, although I did introduce a new variable name (logicalName), I left the 
logic unchanged.

  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;
          }
          LogicalName logicalName =
            new LogicalName(NameGenerator.genString());
          temporary_name = new CUName(null,
                                      target_frame,
                                      logicalName);
          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.

Good, this is the kind of example I was looking for. Unless you can shed light 
on why CUCoreException causes null to be returned, I'll ignore that case.

My best guess about the others, ignoring the null returning cases again, is 
that TranslationInterrupt and CUInterruptedException both look like they're 
reporting that they didn't complete the operation during the request, but that 
they (perhaps?) made progress. The catch-clauses, by extracting a new value 
for temporary_name before retrying, are trying to continue from the progress 
that's been made, rather than starting over again.

Do these guesses seem plausible to you?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM




More information about the e-lang mailing list