If we required toString() methods in our classes, then the existing trace
tool could generate these toString() methods during the build, since it
already parses class definitions and recognises fields within them.
----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:41 -----
Please respond to Fw: FFDC
"Apache AXIS C
I think FFDC should be used to show bugs in Axis C++ not application
errors. Places where I'd like to see FFDC are the default case in switch
statements and where a pointer is unexpectedly null. If we FFDC on all
exceptions, then most FFDCs will be showing simple application errors or
user errors which are already properly reported back to the application in
the exception data. I'd really like to see FFDC where we fail to allocate
storage (a "new" fails) or if we get a SIGSEGV in Axis code.
How will the FFDC handler know how to dump objects in the object stack out
to a file? I guess it will need a toString() method on various classes. In
which case the only objects that ever need to be on the object stack are
the Stub and Call objects, since all other objects are referenced (directly
or indirectly) from Call and Stub. So Call.toString() could call
ClientAxisEngine.toString(), ..., etc, which in turn would call the
toString() method on all other objects.
----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:22 -----
Please respond to FFDC
"Apache AXIS C
time to discuss FFDC again :-)
We'd really like to see FFDC being used in the code. Here are some
FFDC is meant to be used in areas where the exception was completely
unexpected. In WebSphere application server FFDC consists of two elements.
1. The Object Stack
is a list of “useful things to have” so that when an FFDC situation occurs
the FFDC handler has some information as to what state objects were in
prior to the Failure. This system is only as good as the information given
put on the stack and relies on developers putting the appropriate objects
to the stack.
2. FFDC at every exception
Websphere application server originally expected every exception to have an
FFDC record output. This led to situations where FFDC was being produced
and the exception was being thrown back up the stack. The next catcher
would then produce more FFDC. This is obviously not a good system.
I don't believe that it's possible to automate the putting in of FFDC and
that it's a completely manual process - thoughts?
Does everyone agree that we should have the Object stack or do we just want
an FFDC API only? I think the Object stack would be a good idea in certain
circumstances - it does require that you know the code-paths (and there
respective entry points). However, we really only have a couple of these
paths so it should be fairly obvious?