About Question enthuware.ocejws.v6.2.75 :

[himaiMinh]

I tried a simple example:

Code: Select all

@WebService  
public class TimeServerImp implements TimeServer {

   @Override
    public void printTime(){
        System.out.println(System.currentTimeMillis());
        throw new RuntimeException();
    }
}

Code: Select all

//client code snippet:
try{
             timeServer.printTime();
         }
         catch (RuntimeException e){
             System.out.println("catch run time exception");
             e.printStackTrace();
         }

The output from the client is:

Code: Select all

catch run time exception
javax.xml.ws.soap.SOAPFaultException: java.lang.RuntimeException
	at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
	at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:111)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
	at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
	at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129)
	at $Proxy23.printTime(Unknown Source)
	at ch01.ts.TimeClient.main(TimeClient.java:38)

The specification says the run time exception is unrecoverable. But the client can still catch it.
I think the correct option is "the client should catch the exception and handle it just like checked exception."

[fjwalraven]

The specification says the run time exception is unrecoverable. But the client can still catch it. I think the correct option is "the client should catch the exception and handle it just like checked exception."

No, that is not correct. Yes, you can catch it but not handle it.

You might want to do some research on the differences between checked and unchecked exceptions.

Regards,
Frits

[himaiMinh]

According to the Java tutorial,
"Each catch block is an exception handler and handles the type of exception indicated by its argument."
So, a catch block is the place where the exception is handled.

Like the above example, the client can catch any RuntimeException.
If the service has already defined a checked exception in the <fault> element in the WSDL, the client can handle the exception :

Code: Select all

         try{
                    port.getResult();   //getResult() has define a service specific exception, ComputeException 
               }
          catch(ComputeException e ){...}

Here is one more thing I try:

Code: Select all

  public class MyRuntimeException extends RuntimeException{
    
}

Code: Select all

  @WebService 
   public class TimeServer {
    //Assume this method will always throw a RuntimeException
     public void printTime() {
        System.out.println(System.currentTimeMillis());
        throw new MyRuntimeException();
    }
   }

Code: Select all

 try{
             port.printTime();
         }
         //The client catches this MyRuntimeException , prints stack trace, and terminates
         catch (MyRuntimeException e){
             System.out.println("catch run time exception");
             e.printStackTrace();
         }
    }
      //This method is never called.
       port.getTimeAsString();

If that is not a web service client and a standalone program, the first method (printTime) throws an exception which is caught and handled. The second method (getTimeAsString) will be executed.

But since this is a web service client, when the first method catches the run time exception, the second method never executes. It is because the run time exception is unrecoverable.

[fjwalraven]

Yes, each method must handle either all checked exceptions by supplying a catch clause or list each unhandled checked exception as a thrown exception (Handle or Declare Rule).

You can catch an unchecked (RuntimeException) exception but you normally won't do that because you can't solve its cause (if there is no database available on the server side, you can't get to the correct data that is needed in your business logic)

Regards,
Frits

[howdy2u]

I think the best answer out of those given is:

The Client can catch the exception, but should not do anything with the RuntimeException.

In the real world, you might want to catch the exception and then re-throw it inside an application specific runtime exception. Or just log an exception message and then rethrow.

A better answer would be:
The Client should not catch the exception unless it rethrows an exception in the catch block.

[fjwalraven]

Agree.

Changed the description of the correct option.

Thanks for your feedback!

Frits