GxRest/GxJRS/Responses

From Gcube Wiki
Revision as of 05:59, 5 January 2018 by Manuele.simi (Talk | contribs) (How to use Local Code Exceptions)

Jump to: navigation, search

What are Code Exceptions

Code Exceptions model an approach to simplify and uniform the handling of exceptions (in the Java sense) within RESTful or REST-like services. Instead of creating separate classes for each exception type, the idea behind Code Exceptions is to use a single, system-wide exception class. And make it extend WebApplicationException (from javax.ws.rs) that in turn extends RuntimeException.

A Code Exception is capable to hold an error code and an associated message, wrap them into a REST response and return them to the caller.

Major advantages of Code Exceptions are:

  • abstract over an error response returned by a REST resource method
  • throw an error response wherever the developer feels it is safe to terminate the execution
  • provide a single (and self-documented) point where to declare error codes and messages returned by the webapp
  • reduce the class count in a project (not to mention in a system) avoiding the proliferation of custom Exception classes
  • simplify the method declaration (RuntimeExceptions do not need to be declared)
  • simplify the client code that manages only the error codes it is capable to handle
  • remove the need to declare exceptions that sometimes aren’t going to be handled anyway.

Distribution

CodeExceptions are available as part of the gCube eXtensions to the Rest Protocol library (to be released).

How to use Code Exceptions

The following code snippets are extracted from the new Resource Manager service.

Declare your Error Codes

The first step is to declare an enumeration of the error codes and associated messages. The enum must extend the ErrorCode interface.

import org.gcube.core.gxrest.exceptions.ErrorCode;
 
public enum RMCode implements ErrorCode {
 
	INVALID_METHOD_REQUEST(0, "The request is invalid."), 
	MISSING_PARAMETER(1,"Required query parameter is missing."), 
	MISSING_HEADER(2, "Required header is missing."), 
	CONTEXT_ALREADY_EXISTS(3, "Context already exists at the same level of the hierarchy."),
	CONTEXT_PARENT_DOES_NOT_EXIST(4, "Failed to validate the request. The request was not submitted to the Resource Registry."),
	INVALID_REQUEST_FOR_RR(5, "Failed to validate the request. The request was not submitted to the Resource Registry."),
	GENERIC_ERROR_FROM_RR(6, "The Resource Registry returned an error.");
 
	private int id;
	private String msg;
 
	private RMCode(int id, String msg) {
		this.id = id;
		this.msg = msg;
	}
 
	public int getId() {
		return this.id;
	}
 
	public String getMessage() {
		return this.msg;
	}
}

Different enums can be created for different resource methods or per REST resource. The granularity is up to the developer.

Throw Code Exceptions

The following method tries to create a Context given certain parameters (not shown).

import javax.ws.rs.core.Response;
import org.gcube.resourcemanagement.manager.io.rs.RMCode;
import org.gcube.core.gxrest.exceptions.WebCodeException;
 
@Path("context")
public class RMContext {
 
  @POST
  public Response create(...) {
 
    //An error condition occurs
    throw new WebCodeException(RMCode.CONTEXT_ALREADY_EXISTS));
 
    //Another error condition occurs
    throw new WebCodeException(RMCode.CONTEXT_PARENT_DOES_NOT_EXIST));
  }
}

Do note that WebCodeExceptions can be thrown by any object invoked within the create method without the need of declaring them (this is because they are RuntimeExceptions too).

By default, a WebCodeException builds a REST Response with a NOT ACCEPTABLE(406) status. It is possible to assign a different status to the response by using another constructor of the class as shown below.

import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.Status;
import org.gcube.resourcemanagement.manager.io.rs.RMCode;
import org.gcube.core.gxrest.exceptions.WebCodeException;
 
@Path("context")
public class RMContext {
 
  @POST
  public Response create(...) {
 
    // ops, the parent context does not exist
    throw new WebCodeException(Response.Status.CONFLICT, RMCode.CONTEXT_PARENT_DOES_NOT_EXIST);
 
  }
}

Receive Code Exceptions

When a client invokes a resource method that throws CodeException, it can access to the returned code(s) and message(s) as follows:

import org.gcube.core.gxrest.exceptions.SerializableErrorCode;
import javax.ws.rs.core.Response;
 
// invoke the create method and get a response.
Response create = target("context").queryParam(...).request()
		.post(Entity.entity(ISMapper.marshal(newContext), MediaType.APPLICATION_JSON + ";charset=UTF-8"));
 
// obtain the error code serialized in the response.
SerializableErrorCode code = create.readEntity(SerializableErrorCode.class);

The code above makes usage of the Jersey testing framework to invoke the create method.

As enums are not POJOs, they cannot be properly serialized in the Response's entity. Because of that, the enum value is converted and returned as a SerializableErrorCode instance.

Access to Error Codes

Once the client fetched the SerializableErrorCode instance, there are two ways to handle the error codes:

  • Use the SerializableErrorCode methods:
System.err.println(String.format("The service says %d, %s",code.getId(), code.getMessage()));
 
switch (code.getId()) {
	case 3:
	  //manage the error with code 3 (CONTEXT_ALREADY_EXISTS, see RMCode)
	  break;
	case 4:
	  //manage the error with code 4 (CONTEXT_PARENT_DOES_NOT_EXIST, see RMCode)
	  break;	
	default:
          //can't manage the other cases
	  break;
}


  • Convert the SerializableErrorCode object back into the original enum value:
import org.gcube.core.gxrest.exceptions.CodeFinder;
import org.gcube.resourcemanagement.manager.io.rs.RMCode;
 
RMCode realCode = CodeFinder.findAndConvert(code, RMCode.values());
 
switch (realCode) {
	case CONTEXT_ALREADY_EXISTS:
	   //manage the error 
	   break;
	case CONTEXT_PARENT_DOES_NOT_EXIST:
	  //manage the error
	  break;	
	default:
          //can't manage the other cases
	  break;
}

CodeFinder is an utility provided by the CodeException package. This case is possible only if the enum with the ErrorCodes is available in a component shared between the Service and the client.

How to use Local Code Exceptions

The CodeException package provides another type of exception called LocalCodeException. Similarly to WebCodeException, a local code exception holds an error code and a message. However, this exception type is intended to be used internally in the webapp to propagate such information whenever the developer feels it's not the right time to terminate the execution of the REST request (thus using a WebCodeException). The same enums extending the ErrorCode used for the web exception can be used to create a local code exception.

Intentionally, they do not extend RuntimeEception because of their declared scope: the error code inside the local exception is intended to be consumed by the webapp, not by the caller (at least, not yet). The method that throws them must declare this behavior in the signature and the method caller must explicitly catch it (just as any other standard Java exception).

At any time, a local code exception can be converted into a web code exception and therefore it is immediately returned to the caller.

The conversion is very simple.

import org.gcube.core.gxrest.exceptions.LocalCodeException;
import org.gcube.core.gxrest.exceptions.WebCodeException;
import org.gcube.resourcemanagement.manager.io.rs.RMCode;
 
 
public class Test {
 
 private void doSomething() throws LocalCodeException {
   throw new LocalCodeException(RMCode.INVALID_METHOD_REQUEST);
 } 
 
 private void callDoSomething() {
   try {
     doSomething();
   } catch (LocalCodeException lce) {
 
     //do something with lce 
     switch (lce.getId()) {
	case 3:
	  //manage the error with code 3 (CONTEXT_ALREADY_EXISTS, see RMCode)
	  break;
	case 4:
	  //manage the error with code 4 (CONTEXT_PARENT_DOES_NOT_EXIST, see RMCode)
	  break;	
	default:
          //can't manage the other cases
	  break;
     }
     //and then return it to the webapp's client
     throw new WebCodeException(lce);
   }
 
 }
}

It's not mandatory to convert a local exception into a web exception. Local exceptions can also just be used as a mean to propagate and handle errors within the webapp. For instance the switch statement in the example above could convert and return the local exception only in the default case (i.e. when the method doesn't know how to recover from a case not managed before).