Re: Methods, Inheritance, Exceptions, etc. (was: Re: Methods in SMIng ?)

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Putzolu, David writes:

David> I'm familiar with the Java and CORBA models - I used C++ in my
David> example just to pick a well known starting point to illustrate
David> that exceptions typically have a fairly rich semantic associate
David> with them.  In particular, one thing common to C++, CORBA, and
David> Java exceptions is that their exceptions follow a different
David> flow of control than just returning an error value.  It is this
David> behavior that makes the appearance of exceptions in the context
David> of SMIng alarming to me.

CORBA IDL is a data definition language and thus similar in nature to
SMIng. Both, CORBA IDL and SMIng, have no concept of control flows as
they have no statements etc. - so I a bit confused why you put C++,
CORBA and Java into one camp.

Anyway, exceptions in the context of a data definition language is
just a formal way to define which errors can occur while invoking a
certain method.

David> That Juergen mentions INSTALL-ERRORS is perhaps illuminating -
David> my reading of SPPI is that INSTALL-ERRORS are a way to indicate
David> that a provisioning class failed to install successfully.
David> INSTALL-ERRORS make sense, and are a special kind of error - is
David> that what is meant with the word exceptions?  If what is being
David> advocated is simply some special types of predefined error
David> codes or types that can be returned to signify exceptional
David> *conditions*, that may be ok - but then we should not call it
David> exceptions - rename it. Just as classes may need to be renamed
David> attribute groupings, maybe exceptions should be called
David> something else.

Looks like we are converging. So do you have a better term that is
less confusing? BTW, the CORBA IDL spec (01-02-33) says:

     "Exception declarations permit the declaration of struct-like
     data structures, which may be returned to indicate that an
     exceptional condition has occured during the performance of a
     request."

Andrea> The idea of exceptions was added afterwards (I think by
Andrea> Juergen, but I may be wrong). I agree that they are two
Andrea> separate things.  The try...catch approach would be very
Andrea> difficult to support.  However, the approach of sending an
Andrea> exception as a standard notification/event is doable.

David> I believe exceptions should definitely be considered as
David> separate items from methods.  WRT notifications/events - in
David> programming languages exceptions are synchronous responses to
David> method invocations (in CORBA they can also be raised in
David> response to attribute manipulations).  My interpretation of
David> events/notifications is an occurrence of some sort that is
David> asynchronously signalled from the controlled entity to the
David> controller (substitute managed for controlled, manager for
David> controller if desired) - e.g., a SNMP TRAP.  TRAPs and error
David> responses to SETs are quite different, so I'd like to better
David> understand what is being advocated here with exceptions.

I agree with you that exceptions are synchronous with the invocation
of a method and should be signalled accordingly. Sure, a method
invocation may lead to new events that might lead to notifications -
but this is IMHO something different from an exception.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>