[i'm redirecting this to the etch forum, as this is a generally useful
answer]
Manoj Ganesan (manogane) wrote:
On the Java side, I am bundling an exception within an exception by
invoking something like, outerException*.initCause(*innerException*)*.
On the C# side, there's a similar property to extract the inner
exception, basically, exception*.InnerException* which is similar to
the Java *exception.getCause() *method. However, when I do this using
the Management Service (and Etch), I don't get this particular field
populated on the C# side. I guess the Etch
serialization/deserialization code doesn't take this into account, and
ignores the field.
In such a scenario, should we ignore this problem, or should we strive
to achieve complete cross-platform compatibility. As it seems to me,
it needs some kind of extra code on the C# side that maps the *cause
*in Java to *innerexception *in C#. Maybe I'm trivializing it. What do
you think is the acceptable scenario?
actually, that is on purpose. generally that inner exception will be an
implementation detail that we don't want to propagate.
in the case of exceptions, the message must tell the whole story. so if
an inner exception is wrapped, the message should also indicate the
problem and perhaps also (but not always) add the message from the inner
exception.
as a counter example, if a user name / password combination fails during
a login sequence, the exact nature of the failure should not necessarily
be reported (because someone might be trying to hack the system and that
might give them an important clue).
so, why bother wrapping?
in a production server environment, you will want to log such exceptions
and their inner structure and record with it some sort of id which is
also reported back to the client. a user, getting this message with an
id, could call up a help desk and ask for further information. and a
help desk person, armed with the id, could research the problem and
report back, armed with the complete traceback and any inner exceptions.
so the cuae bridge, when reflecting an exception to an app or plugin,
should log the message (at verbose level) including the traceback and
any inner exceptions. what id to use? i dunno. the cuae logger is not
very powerful right now and has none. i'd leave that for another day.
scott out
_______________________________________________
Etch mailing list
Etch@developer.cisco.com
_______________________________________________
Etch mailing list
Etch@developer.cisco.com
Cisco Unified Application Environment Developer Forums 
