| [corona-dev] Remote Exception Handling between Corona Client and Corona Server |
|
This discussion started
privately but should really be public so here it is. -----Original Message----- From: Sent: Monday, November 06,
2006 3:19 PM To: Cc: Subject: RE:
ProjectContainerProxy basic error handling OK Piotr, I checked in the
change to have the proxyClass resolve the remote exception type. So the
behavior you should see now is: A: The remote code was
invoked, and an exception was thrown that is declared in the proxy interface,
or is visible to the proxy interface's classloader - you'll get the declared
exception. B: The remote code was
invoked, and an exception was thrown that wasn't declared in the proxy
interface, and is not visible to the proxy interface's classloader - you'll get
a SOAClientException. C: The remote code was never
invoked, there was a communication error - you'll get a SOAClientException. I've added some code to the
SOAClientException so that you can query to see if the error is a network error
and if the error is recoverable. So things like a miss-configured axis won't be
recoverable, but things like a connection refused will be (in other words,
server is unavailable but may return). I don't have the code in the proxy to populate
these fields, so for now everything defaults to recoverable non-network error. I'll try and get the detail
code into the SOAClientException shortly. Cheers, Joel -----Original Message----- From: Sent: Monday, November 06,
2006 12:03 PM To: Cc: Subject: RE:
ProjectContainerProxy basic error handling > No matter what, we
shouldn't require a kill -9 to shut down! That's no problem it's small
change within CoronaWorkbenchListener.preShutdown method, line
PCXViewManager.getManager().hideAndCloseProjects() was causing the problem with
closing the workbench. It will be surrounded with
try catch block... Piotr, -----Original Message----- From: Sent: Monday, November 06,
2006 5:39 PM To: Cc: Subject: RE:
ProjectContainerProxy basic error handling As far as the proxyClass
delegation stuff, it's a one-liner. I say we go for it. As for distinguishing
communication errors, I think I just need to get a bit more familiar with the
AxisFault types so I can tell what comes from the send chain vs the receive
chain. I do think our code should
be able to withstand a runtime exception, however. No matter what, we shouldn't
require a kill -9 to shut down! Cheers, Joel -----Original Message----- From: Sent: Monday, November 06,
2006 11:33 AM To: Cc: Subject: RE:
ProjectContainerProxy basic error handling >Whah? There are other
ways to get runtime exceptions (like our old buddy >NullPointerException) -
so there's no handling that deals with Throwable? In most cases there is a
standard eclipse handling, that the error message will go to the eclipse error
log. But not in all cases :-(. > This is really pretty
easy to implement. Shall I make the change? > Also, the
SOAClientException carries the reason from the AxisFault. My > intent was not to
surface the AxisFault too directly, as we may very > well swap out the SOAP
layer in the future (or at least support > multiple SOAP layers). The problem is that M5 is
coming and I'm not sure if we should add it or not ;-). What do you suggest? What
exception should be thrown from methods declared in IContainerManager
(Exception, CoronaException, some other) ?? Piotr, |