[
https://issues.apache.org/jira/browse/GUACAMOLE-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351627#comment-16351627
]
Michael Jumper commented on GUACAMOLE-499:
------------------------------------------
{quote}
Unless there's some specific reason we're not?
{quote}
I'd have to check the code history, but my best guess would be that the
{{getStatus()}} function of {{GuacamoleException}} (or the mappiing between the
status codes and HTTP status codes) was added after the exception handling
within the REST API, and thus the REST API needed its own mapping.
As the {{getStatus()}} function is meant to return the Guacamole-specific
status code representing the error indicated by the particular subclass of
{{GuacamoleException}}, and {{getHttpStatusCode()}} is meant to return the
nearest equivalent to that Guacamole-specific status, I don't see any problem
with this at a semantic level. It's worth testing that existing error
conditions still produce the expected error codes, but I suspect that will be
the case.
> REST API Error Codes should come from GuacamoleStatus
> -----------------------------------------------------
>
> Key: GUACAMOLE-499
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-499
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-client
> Reporter: Nick Couchman
> Assignee: Nick Couchman
> Priority: Trivial
>
> Currently the RESTExceptionWrapper catches specific GuacamoleException-types
> and throws specific Response.Status types for those exceptions. Since the
> HTTP response code is embedded in the Exceptions via the GuacamoleStatus
> object in those exceptions, and that status is used in the tunnel, already,
> it seems to make sense to use this code in the REST API, as well.
> Unless there's some specific reason we're not?
> PR coming soon...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
