NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/ai/shells/376

Internet Message Format | 1992-07-30 | 3.7 KB

Xref: sparky comp.ai.shells:376 comp.programming:2139 comp.software-eng:3021
Path: sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!sugar!claird
From: [e-mail] (Cameron Laird)
Newsgroups: comp.ai.shells,comp.programming,comp.software-eng
Subject: Commercial exception-handling as rule evaluation [LONG]
Message-ID: <[e-mail]>
Date: 31 Jul 92 15:34:13 GMT
Article-I.D.: NeoSoft.1992Jul31.153413.27708
Organization: NeoSoft Communications Services -- [phone]
Lines: 66

I have a precise situation in mind, but the questions I have about it
are open-ended.

I program a lot of exception-handling into the commercial applications
for which I have responsibility.  Examples:

        a.  if a resource manager in the process of initializing
            shared-memory communications detects what appears to
            be an orphaned shared-memory segment, then it writes
            an announcement of that observation to a log file;
        b.  if a user specifies a perfume recipe with a negative
            quantity of verbena extract, then the application
            prints a diagnostic to the screen, and halts;
        c.  if an operator requests the manifests for the con-
            tents of a rail car that in fact is idle, a diagnostic
            appears, along with a pop-up listing likely identifiers
            for cars that *are* in transit.

This if-then formulation suggests that an expert system--perhaps just a
small one--should come into play somewhere.  My first question, then, is
I.  What do people think of engineering (some? all?) exception-handling
    as an explicit expert system?

Advantages:  I just feel good about a structure which emphasizes the
uniformity of an approach.  I can derive all sorts of division-of-labor
advantages by partitioning exception-handling in this way, and a rule-
manipulation system seems quite natural.  In particular, a uniform
approach will streamline effective communication with the user; if he
or she comes to expect that faults will be reported in a more-or-less
uniform way, then he or she will understand the reports better, and
trust them more.

Disadvantages:  folklore has it that exception-handling is hard to
automate; for example, even fans of yacc(1) and lex(1) complain that
error-recovery is next-to-impossible.  That's not really the same
issue, but part of the yacc-lex history is the realization that users
deserve error information from a variety of algorithmic levels.  Another
disadvantage, of course, is that I'll need to make some changes if I
aim to engineer this better than my current naive approach.  This leads
to
II.  what opinions do folks have on available expert system libraries,
    which can be linked into C++ projects?

At a sheer minimum, even in C, I can write a crude method

        BOOLEAN performIfNecessary(BOOLEAN predicate, ACTION fcnptr)

and make (most?) all the exception-handling visible by vectoring it
through this.  If I were programming within such an ES as Guru, state
variables of my application would (likely) be global, and I could get
at whatever I need from my rule set.  Is there some clever way to define
a more sophisticated inference engine within C++, though, which pierces
through the encapsulation of instance variables, while properly factoring
out the inferential mechanism?  Are there shareware or commercial (class)
libraries?

I'm not sure what my audience will be for such diffuse questions.
Please let me know if I need to clarify particular points.

I haven't seen a comp.ai* FAQ for a while.  My apologies if I've missed
something there.
--

Cameron Laird
[e-mail] ([e-mail])    [phone]
[e-mail] ([e-mail])      [phone]