Java Spring ExceptionHandler控制器语法和良好实践
我想在Spring中正确地处理我的异常，所以我有一个关于exceptionHandler语法的问题：如果异常处理程序捕获了特定的异常，那么在控制器中抛出特定的异常可以吗？
public class UnknownUserException extends Exception {
private static final long serialVersionUID = 1L;
public UnknownUserException(String message) {
super(message);
}
}
@ControllerAdvice
@ResponseBody
public class ControllerExceptionHandler {
@ExceptionHandler(UnknownUserException.class)
@ResponseStatus(value = HttpStatus.NOT_FOUND)
public ErrorMessage unknownUserExceptionMessage(UnknownUserException ex, WebRequest request) {
ErrorMessage message = new ErrorMessage("The user doesn't exist: " +ex.getLocalizedMessage(), ex);
return message;
}
}
@GetMapping({"/user/{id}"})
public ResponseEntity<UserProfileDto> getById(@PathVariable Long id) throws UnknownUserException {
UserProfileDto user = userService.findById(id);
return ResponseEntity.ok(user);
}
共有1个答案
在理想的场景中，当您知道服务方法将抛出UnknownUserException时，应该立即抛出异常。您的控制器建议应该能够处理该异常。ContollerAdvise将处理在执行请求期间引发的任何匹配异常，而不管异常的来源是什么。
有关处理异常的其他选项，请参阅此链接
-
问题内容： 使用语法时如何订阅属性更改？ 问题答案： 只需绑定相关上下文即可。 示例：http：//jsbin.com/yinadoce/1/edit 更新： Bogdan Gersak的答案实际上是等效的，两个答案都尝试在正确的上下文中进行绑定。但是，我发现他的答案更干净。 话虽如此，首先，您必须了解其背后的基本思想。 更新2： 对于那些使用ES6的人，通过使用它们可以获得具有正确上下文OOTB
-
问题内容： 缩进SQL语句的公认做法是什么？例如，考虑以下SQL语句： 应该如何缩进？非常感谢。 问题答案： 我喜欢将所有的“，”放在前面，这样，当SQL编辑器在X行出现错误时，我就永远不会搜索它们。 对于那些不使用这种类型的编写SQL语句的人来说，这是一个示例。两者都包含缺少逗号的错误。 在第一个示例中，我发现更容易，更快捷。希望本示例向您展示更多我的观点。
-
问题内容： 我正在使用lucene为文档建立索引并执行搜索，之后我立即将其删除。所有这一切都可以看作是有点原子的动作，包括以下步骤： 索引（作者） - >搜索（搜索者） - >按得分获取文档（阅读器） - >删除文档（阅读器） 该操作可由同一索引上的多个并发线程执行（使用）。 重要说明： 每个线程处理一组单独的文档，因此一个线程不会碰到另一个线程的文档 为此，我有几个问题： 1）我应该使用的单个实
-
我的大部分编程经验都是用C++编写的。我正在学习Javafx中的许多优秀特性，但到目前为止，我最大的障碍是在用Javafx编写应用程序时是否使用了良好的编程实践。首先，我被教导要在C++中保持“main函数”尽可能干净，所以它主要包含我自己的类对象及其方法。在外汇工作时，这是一般的好做法吗？即在包含start方法的主类之外创建一些类，然后将这些类的对象添加到start方法中？这里有一个例子： 这个
-
问题内容： 我只是想知道哪种语言是开发支持大量（数千）用户的游戏服务器的理想选择？我涉足python，但意识到这不会给所有内核带来线程（这意味着8核心服务器= 1核心服务器）会带来太多麻烦。我也不太喜欢这种语言（那种“自我”的东西使我很生气）。 我知道C ++是性能方面的工作语言，但我讨厌它。我不想处理它的草率语法，我喜欢我的手被托管语言握住。这使我接触到C＃和Java，但是我对其他语言持开放态度
-
问题内容： 过去，我使用以下方法读取大量代码： 这样做是惯例吗？ 优点和缺点是什么？ 在我看来，这就像完成异常的“ Agent Orange”方式 编辑 处理方法中的预期异常 引发意外异常（一对一） 不在乎错误 那是路要走吗？ 问题答案： 你不应该扔。这就是为什么。 Throwable是可抛出的事物层次结构的顶部，由and组成。由于根据定义是由不可挽救的条件引起的，因此将它们包括在方法声明中是没有