Yes that would be perfect.
I have been looking at the mechanism for mapping api exceptions to response building class in che:
It seems that ExceptionMapper<T> classes are responsible for doing that, and you have provided two implementations:
ApiExceptionMapper and DefaultExceptionMapper. ApiExceptionMapper is probably bound using Guise , and the Default one is added manually in ProviderBinder(everrest).
The proper mapper lookup happens in RequestHandlerImpl (everrest.core), and if no proper mapper is found, there is a fallback code,
Which does this:
}
else
if (cause
!= null) {
errorResponse = createErrorResponse(errorStatus,
cause.toString());
}
else
if (e.getMessage()
!= null) {
errorResponse = createErrorResponse(errorStatus,
e.getMessage());
}
Which is exactly what happens in the use case I have sent in the previous mail.
I don't really understand why DefaultExceptionMapper is not selected (it fits to every Exception), maybe because the exception thrown is RuntimeException or derived
from it. But if this is the case, it does not explain another use case where I receive the following response:
com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 5 path $
MalformedJsonException is subclass of Exception, and yet the
DefaultExceptionMapper logic is not called. Perhaps exceptions are wrapped in another class, which prevents the proper mapper from recognizing them ?
Any insight on those issues will be greatly appreciated,
Best regards,
Sergey
From: che-dev-bounces@xxxxxxxxxxx [mailto:che-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eugene Ivantsov
Sent: Tuesday, November 1, 2016 2:59 PM
To: che developer discussions <che-dev@xxxxxxxxxxx>
Subject: Re: [che-dev] Internal server errors in che 3.x
Hi,
I think just having Internal Server Error isn't enough for debugging purposes. Would it be ok having Internal Server error while <what causes the error>, e.g. while getting runners.
On Tue, Nov 1, 2016 at 2:31 PM, Kuperman, Sergey <sergey.kuperman@xxxxxxx> wrote:
Hello,
We have noticed that in many cases che api's return internal system information in responses of 500 (internal server error)
For example :
PUT /di/project/workspacewe2ls3c0hsz0nnrs/html5 HTTP/1.1
Host:
devxmasterdi-i074921trial.dispatcher.hanatrial.ondemand.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
X-CSRF-Token: 4D09B3CE05DDD95D3C8119EE380D6486
X-Requested-With: XMLHttpRequest
Referer:
https://devxmasterdi-i074921trial.dispatcher.hanatrial.ondemand.com/
Content-Length: 2
Connection: close
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Expires: Thu, 01 Jan 1970 00:00:00 UTC
Date: Mon, 31 Oct 2016 08:47:01 GMT
Vary: Accept-Encoding
Content-Type: text/plain
Content-Length: 152
Connection: close
Server: SAP
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
while trying to invoke the method org.eclipse.che.api.project.shared.dto.ProjectUpdate.getRunners() of a null object loaded from local variable 'update'
The message (red) discloses internal system information to the api user, and does not really help him deal with the issue.
From our point of view, generalized message i.e. "Internal server error" would be preferred, since this internal message along with stack
trace is already safely logged by the backend.
What is your stand point to this issue ? Can we expect this behavior to change ?
Thanks in advance for your input.
Best regards,
Sergey Kuperman,
DI Cloud Exp DevX | SAP Labs Israel | 15 Hatidhar st. | Raanana 43665, Israel
T
+972-(0)9-777-9513
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
--
