Исключение Java и ошибка HTTP 500
Есть ли какое-либо отношение к исключениям Java на стороне сервера и коду ошибки 500 для http, который является Internal Server Error. Это происходит из-за unhandled exceptions в блоке catch или из-за исключений unchecked, которые возникают из-за runtime.
Как я мог прийти к выводу, для меня это проект Apache Camel, который имеет spring-boot-starter-parent и имеет Spring Quartz Configured внутри. В основном REST обращается через пробеги аутентификации OAuth 1.0.
Тестирую свое приложение от Swagger. Я не могу сделать вывод, что,
OAuth 1.0Аутентификация успешна или нет- Подпрограммы обработки ошибок не могли захватить конкретный, -
error codeв проекте, так как это в основномunhandledиruntime exception.
Swagger дает следующий ответ с кодом ошибки 500.
"<Error><Message>An error has occurred.</Message><ExceptionMessage>Object reference not set to an instance of an object.</ExceptionMessage><ExceptionType>System.NullReferenceException</ExceptionType><StackTrace> at API.ExecutionTimeFilterAttribute.OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
\n at System.Web.Http.Filters.ActionFilterAttribute.OnActionExecutedAsync(HttpActionExecutedContext actionExecutedContext, CancellationToken cancellationToken)
\n--- End of stack trace from previous location where exception was thrown ---
\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
\n at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
\n--- End of stack trace from previous location where exception was thrown ---
\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
\n at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
\n--- End of stack trace from previous location where exception was thrown ---
\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
\n at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()
\n--- End of stack trace from previous location where exception was thrown ---
\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
\n at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__2.MoveNext()
\n--- End of stack trace from previous location where exception was thrown ---
\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()</StackTrace></Error>"
Даже с неправильным secret key, consumer key, это тот же сценарий.
Я предполагаю, что ключи не подходят для обоих сценариев.
Однако я хотел бы знать,
is 500 error code is common for unhandled exceptions & unchecked runtime exceptions or there we will be 400 series
Как я могу судить о сценарии тестирования, если возникает код ошибки http (500), отличный от пользовательского кода ошибки Java, который обрабатывается в коде и на который был дан ответ как часть строки ответа для вызовов REST.
Код запутан, поэтому try..catch обрабатывает серию 400. В случае unchecked exceptions это будет серия 400 или как она будет?
http 500 также встречается при утечке памяти, поэтому ваш сервер в это время будет вне метапространства, и если это так, то это будет происходить при каждом запросе на отдых.
Ответы 1
What you could do here is to add an ExceptionHandler and debug the root cause of the exception. See: http://www.baeldung.com/exception-handling-for-rest-with-spring OR http://zetcode.com/springboot/exceptionhandler/ OR http://www.springboottutorial.com/spring-boot-exception-handling-for-rest-services
Большинство фреймворков и библиотек (используемых для создания RESTful API) по умолчанию выдают ошибку 500 для любого неперехваченного (или во время выполнения) исключения, и это только потому, что они не могут определить фактическую бизнес-логику.
Но ответственность за обработку любых неперехваченных (или во время выполнения) исключений и их преобразование в правильный код HTTP-ответа в соответствии со стандартами REST API ИЛИ в соответствии с бизнес-сценариями лежит на разработчике на стороне сервера. См .: http://www.restapitutorial.com/httpstatuscodes.html для идеального сопоставления кодов ответов HTTP с вариантами использования.
P.S. It is like asking: should we store a set of integer values in an array of Strings or in an array of integers. Language/Framework does not mandate these nitty gritty details, right? (I mean sometimes they do, with say, Generics in Java, but there is a limit :))
опубликуйте свой блок try catch, который обрабатывает серию 400?