Please comment on this pseudocode for exception handling.
The majority of the client and server code would throw
subclasses of DetailedException, which would not be axis-
specific. That would be converted to and from an
AxisFault, and a generic fault would be sent over the
wire (illustrated at the end).
Main {
main() {
try {
s = MyCallerOfWebService.callOperation();
// display s to user
}
catch ( DetailedException e ) {
displayDetailedExceptionDialog( e );
}
catch ( Exception e2 ) {
displayGenericExceptionDialog( e2 );
}
}
}
// main() calls this:
MyCallerOfWebService { // axis-specific class
String callOperation() {
try {
webService.operation();
}
catch ( Exception e ) {
// e will most likely be an AxisFault,
// but could be a RemoteException?
throw AxisExceptionFactory.convertToDetailedException( e );
}
}
}
// this is the webservice implementation on the server:
MySoapBindingImpl {
String operation() {
try {
return someClass.doSomething();
}
catch ( Exception e ) {
throw AxisExceptionFactory.convertToAxisException( e );
}
}
}
// this does the actual work of the webservice on the server:
SomeClass {
String doSomething() {
try {
someDatabaseOperation();
}
catch ( SQLException e ) {
throw new DatabaseException( 4, 327, e.getMessage() );
}
}
}
// these are the non-axis-specific exceptions
// that are used on the client and the server:
DetailedException {
// when created, stores off stacktrace,
// state of server, file/line where exception
// occurred, etc.
}
DatabaseException extends DetailedException {
DatabaseException( int majorCode, int minorCode, String msg ) {
// majorCode is a key to the generic message,
// ex.: "can't open database"
// in the AxisFault, this will be the faultstring value
// minorCode is a key to the specific message,
// indicating where the exception occurred and
// what the user can do about it. This code will be sent
// in the detail section of the AxisFault, and my client
// app will look it up and display it to the user.
// Other client apps will not understand this value unless
// they've been specifically programmed to do so.
// msg will be sent in the detail part as well, and will
// be additional information
}
}
// this axis-specific class converts between axis-specific
// exceptions and non-axis-specific exceptions:
AxisExceptionFactory {
AxisFault convertToAxisException( e ) {
// create and return an AxisFault, filling
// out its various fields from 'e'
// the specific subclass of 'e' will be stored in the detail section
}
DetailedException convertToDetailedException( Exception e ) {
if ( e instanceof AxisFault )
// create an exception based on the subclass stored in the detail
// section.
// For instance, if a DatabaseException was sent, the name
// 'DatabaseException' will be stored in the detail section
// fill out the other fields of the DetailedException
// from the majorCode, minorCode, etc. in the detail section
}
}
The actual response would look like:
faultcode: axis:Server
faultstring: Database not running
detail:
majorCode: 4
minorCode: 327
msg: some additional information
file: SomeClass.java
line: 15
num-server-threads: 200
stack-trace: at blah(334) at blah2(332)...
etc. etc.
displayDetailedExceptionDialog would convert 4 and 327 into
strings to be shown to the user
other clients would just know how to show 'Database not running'
On 11 Sep 2004 at 16:08, [EMAIL PROTECTED] wrote:
> Im certainly no expert and I was asking the same thing but from my
> understanding, you can extend remote exception and catch them but you
> loose interop so the best way is to extend axis fault and use constants to
> set fault codes which you can then get at client side. The catch is you
> cant (or I cant anyrate) catch them but rather have to wrap some ugly
> logic / casting to figure out what specific fault you got when you catch
> the axis fault. You can then do setFaultDetail(localised string) etc.
>
> Richard Hansen posted some interesting stuff @
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg03552.html
>
> /tom
