I've updated the snippet in https://pastebin.com/3nzsjFi1 to demonstrate a potential workaround using a custom StatusService and special client-side handling. This example just deals with a StringRepresentation to pass a custom error status description, but the technique could be generalized to use an arbitrary custom error representation.
The use of the client proxy mechanism is orthogonal to this workaround, but since this snippet was originally about how ResourceExceptions passed through this mechanism don't preserve full error information, I've kept it in. The heart of the problem, as I see it, is that the ClientInvocationHandler throws away important information when handling errors. Until that's changed, the best you can do is to explicitly manage the error entity, as in the workaround in the snippet. It's not pretty, but it works. --tim On Tue, Jul 10, 2012 at 8:36 PM, Richard Berger <rich...@landisfamily.org>wrote: > And one further note, wrapping the client resource does not seem to change > the results. > > That is to say, going from: > ClientResource commitsResource = new ClientResource(getContext(), > commitsRef); > commitsRep = commitsResource.get(); > > To: > ClientResource clientResource = new ClientResource(commitsRef); > CommitmentsResource commitsResource = > clientResource.wrap(CommitmentsResource.class); > Representation commitsRep = null; > commitsRep = commitsResource.represent(); > > Changes nothing.... > RB > > On Tue, Jul 10, 2012 at 4:22 PM, Richard Berger <[hidden > email]<http://user/SendEmail.jtp?type=node&node=7578193&i=0> > > wrote: > >> Yes, I only see this problem when I go through my Restlet client, not >> when using a browser. In order to make sure the API I am developing is >> usable by real client developers, I figured I should also build a client. >> I chose Restlet as the technology for that client - perhaps that wasn't >> the best possible choice (if no one else does that). >> >> Thanks for the response... >> RB >> >> >> On Tue, Jul 10, 2012 at 2:09 PM, Bjorn Roche [via Restlet Discuss] <[hidden >> email] <http://user/SendEmail.jtp?type=node&node=7578193&i=1>> wrote: >> >>> I can't help you directly, but I can say that I use restlet server (but >>> not client) and I am pretty sure I DON'T have this problem. Is this a bug >>> in the client that it can't access the http status message? That is what >>> I'm gathering from the thread you linked as well. >>> >>> bjorn >>> >>> On Jul 10, 2012, at 1:18 PM, Richard Berger wrote: >>> >>> > My question is similar to that raised at: >>> > >>> http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629 >>> > >>> http://restlet-discuss.1400322.n2.nabble.com/Sending-server-side-exceptions-error-codes-back-to-client-td7219795.html#a7229629 >>> > , but since that has not been answered and this seems like a really >>> basic >>> >>> > issue, I thought I would try posting again. >>> > >>> > The question is simply this - how to get the details of an >>> error/exception >>> > that occurs on the Restlet server back to my Restlet client? >>> > >>> > I can see how to do this if my client were just a browser (I could >>> construct >>> > an HTML page on the server and return it). >>> > >>> > I thought that it would be pretty simple - set the Status code and >>> Status >>> > description. But as the discussion above points out, that doesn't >>> work. >>> > >>> > I then thought that I could just set the Status code and send back a >>> String >>> > Representation of the error message. But that doesn't work either. >>> In >>> > particular, if I have: >>> > msg = "error xyz occurred"; >>> > this.setStatus(Status.SERVER_ERROR_INTERNAL, msg); >>> > StringRepresentation result = new StringRepresentation(msg, >>> > MediaType.TEXT_PLAIN); >>> > return result; >>> > The client side call: >>> > commitsRep = commitsResource.get(); >>> > Sets commitsRep == null (!). Note: it is only set to null when the >>> status >>> > != 200. >>> > >>> > So, I could set the status to 200 and then return the >>> StringRepresentation >>> > and then on the client, check to see if I have a StringRepresentation >>> (which >>> > would be an error) or some other type (which would be a success). >>> > >>> > But surely there has got to be an easier way - what am I missing? (I >>> have >>> > created my own StatusService on the server, I have thrown my own >>> exception, >>> > but no joy). >>> > >>> > Thanks in advance for any hep - and thanks to Tim P for collecting all >>> the >>> > links in the thread above - but those weren't enough for me to work >>> around >>> > the problem. >>> > >>> > RB >>> > >>> > -- >>> > View this message in context: >>> http://restlet-discuss.1400322.n2.nabble.com/Handling-exceptions-errors-when-using-Restlet-for-Client-and-Server-tp7578190.html >>> > Sent from the Restlet Discuss mailing list archive at Nabble.com. >>> > >>> > ------------------------------------------------------ >>> > >>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2982701 >>> >>> ----------------------------- >>> Bjorn Roche >>> http://www.xonami.com >>> Audio Collaboration >>> http://blog.bjornroche.com >>> >>> ------------------------------------------------------ >>> >>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2982833 >>> >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> >>> http://restlet-discuss.1400322.n2.nabble.com/Handling-exceptions-errors-when-using-Restlet-for-Client-and-Server-tp7578190p7578191.html >>> To unsubscribe from Handling exceptions/errors when using Restlet for >>> Client and Server...., click here. >>> NAML<http://restlet-discuss.1400322.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>> >> >> > > ------------------------------ > View this message in context: Re: Handling exceptions/errors when using > Restlet for Client and > Server....<http://restlet-discuss.1400322.n2.nabble.com/Handling-exceptions-errors-when-using-Restlet-for-Client-and-Server-tp7578190p7578193.html> > Sent from the Restlet Discuss mailing list > archive<http://restlet-discuss.1400322.n2.nabble.com/>at Nabble.com. > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2983901
