Question

I am using Restlet version 2.0.15

I am implementing a service that generates a potentially large zip file on the fly to be
downloaded by a ReST client. In generating this file, an error may occur, and when it
does I would like to give a meaningful error response to the client.

My setup includes:

In the main, an instance of Application is constructed, and the Component.setStatusS​ervice(StatusService​) and
Application.setStatu​sSevice(StatusServic​e) are invoked with MyStatusService (Extends StatusService)
and, and MyStatusService overrides:

    public Representation getRepresentation(Status status, Request request, Response response) {

    public Status getStatus(Throwable throwable, Request request, Response response) {

    public Status getStatus(Throwable throwable, UniformResource resource) {

…

When I handle the GET request from the client, I set the entity in the response
(Response.setEntity(​Representation) with MyRepresentation which extends OutputRepresentation.
The MyRepresentation class overrides the method:

   public void write(WritableByteChannel writableChannel)

which calls the overridden method:

   public void write(OutputStream outputStream)

which does the work of generating the zip file.

When I run it, the following happens:

ServerCall.sendRespo​nse(Response) calls –>

ServerCall.writeResp​onseBody(Representat​ion, WritableChannel, OutputStream) –> calls

MyRepresentation(extends OutputRepresentation​).write(OutputStream​)

which finds a problem (as expected) with the (intentionally bad for testing reasons) request,
and wants to give the client a meaningful response. So it throws an exception (should it be a ResourceException, or any exception?), which is caught in

ServerAdapter.commit​(HttpResponse) 

but after this point, no call is made to any method in MyStatusService, so the client does not
get a meaningful message, only a 500 status.

Is there a way to control the status (and ideally give an informative message) to the client?

Thanks for any info,

• Jim

Answer 1

This is actually a bug in Restlet. The issue is logged at:

https://github.com/restlet/restlet-framework-java/issues/670