手机网站开发软件,做网站排名公司推荐,深圳10大品牌策划公司,wordpress首页添加登录目录
概述#xff1a;
综合实例#xff1a;
继承 ResponseStatusException-自定义异常类
继承 ResponseStatusException-自定义响应头信息
继承 ResponseStatusException-定制更多异常处理逻辑
继承 ResponseStatusException-根据异常发生的上下文动态改变 HTTP 状态码…目录
概述
综合实例
继承 ResponseStatusException-自定义异常类
继承 ResponseStatusException-自定义响应头信息
继承 ResponseStatusException-定制更多异常处理逻辑
继承 ResponseStatusException-根据异常发生的上下文动态改变 HTTP 状态码 概述
从 Spring 5.0 开始引入特别适用于 Spring WebFlux也可以在 Spring MVC 中使用使用 ResponseStatusException 可以在代码中的任何地方抛出特定的 HTTP 状态码比如 404 NOT FOUND 或 400 BAD REQUEST以及一个可选的错误消息这个类继承自 RuntimeException因而它是一个不受检异常unchecked exception你不需要在方法签名上声明它也不必强制捕获它其主要的目的是通过编程方式控制异常以及相应的 HTTP 状态码和错误信息的返回ResponseStatusException 类的主构造函数如下status一个 HttpStatus 枚举值表示要返回的 HTTP 状态码reason一个表示错误详情的 String这个消息可能会返回给客户端所以在设置时要注意安全性和敏感信息泄露的问题cause引发异常的原始 Throwable 对象这不会直接发送给客户端通常用于日志记录目的有几种构造函数版本不一定全部需要传入reason或cause您可以根据实际需求使用它们
综合实例
下面是一个简单的例子展示如何在控制器方法中使用 ResponseStatusException在这个例子中当找不到给定 ID 的 item 时会抛出 ResponseStatusException并且返回状态码 404 NOT FOUND 以及错误信息 “Item not found”由于 ResponseStatusException 是RuntimeException的子类Spring 框架会捕捉到这个异常并将其转换成相应的 HTTP 响应返回给客户端这个机制允许开发者以非常灵活的方式处理各种各样的异常情况
继承 ResponseStatusException-自定义异常类
在 Spring Boot 应用程序中ResponseStatusException 是一个构建好的异常类它可以被直接使用来返回特定的 HTTP 状态代码和消息你可以在方法中直接抛出它Spring 框架将负责将异常转化为对应的 HTTP 响应但是如果你有特定的需求比如希望在你的应用程序中创建一系列具有固定状态码和自定义处理逻辑的异常你可以继承 ResponseStatusException下面是一个简单的例子定义了一个继承自 ResponseStatusException 的自定义异常类在你的 Spring Boot 应用中使用自定义异常当 CustomBadRequestException 被抛出时Spring 框架会捕捉到这个异常并且根据异常内的信息返回一个 HttpStatus.BAD_REQUEST (400 错误码) 的 HTTP 响应给客户端并带有 “这里是错误信息” 作为响应体中的错误描述通过这种方式你可以定义不同的自定义异常类型来处理你应用程序中不同的错误情况并返回合适的 HTTP 响应
继承 ResponseStatusException-自定义响应头信息
在继承自 ResponseStatusException 的自定义异常类中重写 getResponseHeaders() 方法可以让你添加或者定制返回给客户端的 HTTP 响应头默认情况下ResponseStatusException 没有响应头或者只有基本的响应头通过重写这个方法你可以根据你的业务逻辑需要添加一些特殊的响应头信息例如你可能想添加一个关于错误的链接一个特殊的错误追踪 ID或者控制缓存的头信息下面是一个例子演示了如何在自定义异常中重写 getResponseHeaders() 方法来添加一个自定义的响应头 在控制器中抛出这个自定义的 CustomBadRequestException 将会导致 Spring 框架处理这个异常并在最终的 HTTP 响应中包含 ‘X-Custom-Error’ 这个头信息使用自定义的响应头可以提供更多的上下文信息给调用者或者用来传达非标准的、特定于应用的消息这是一个扩展标准异常处理行为并高度定制异常返回信息的强大方式要注意的是你应该谨慎添加响应头确保它们不会暴露敏感信息或者与你的 API 设计冲突
继承 ResponseStatusException-定制更多异常处理逻辑
在继承 ResponseStatusException 的自定义异常类中除了getResponseHeaders()之外你可能会考虑重写几个其他重要的方法来进一步定制你的异常处理逻辑
getMessage(): 重写这个方法可以让你改变异常的错误消息 这个消息通常会被用在日志中也可能在一些情况下返回给客户端取决于你的错误处理配置getStatus(): 如果你想根据异常发生的上下文动态改变 HTTP 状态码可以重写 getStatus() 方法getCause(): 如果你的自定义异常包装了另一个异常你可以通过 getCause() 方法提供原始的异常这对于调试和错误跟踪是非常有用的printStackTrace() 和 getStackTrace(): 这些方法可以被用来获取和打印异常的堆栈追踪
通常这些方法的默认实现足够用了但如果需要的话你可以提供更多的信息或者定制格式在实际业务情况中我们可以重写异常类的这些方法来增强错误处理的能力例如记录额外的调试信息、创建更为详细的错误消息等让我们来创建一个更切实的业务场景来展示这一点假设我们有一个在线电商平台当用户尝试创建订单时如果库存不足我们希望抛出一个自定义的异常在这个自定义异常中我们可以重写 getMessage() 方法来提供更丰富的信息并重写 printStackTrace() 和 getStackTrace() 方法来添加关于库存不足的特定上下文信息
在这个示例中
getMessage() 被重写以返回一个更为详细的错误信息printStackTrace() 被重写以打印特定的业务相关错误信息getStackTrace() 被重写以添加自定义的堆栈跟踪元素这可能对调试有帮助显示出是在检查库存时出现了问题getStatus() 被重写以返回一个特定的HTTP状态请注意通常这也可以通过在抛出异常时传递不同的 HttpStatus 枚举值给构造函数来实现getMessage() 被修改以增加更多的业务信息如最后库存同步时间
通过这样重写这些方法我们可以提供更加具体的错误状态和信息以便在记录日志、返回给客户端、调试等方面提供有用的上下文
继承 ResponseStatusException-根据异常发生的上下文动态改变 HTTP 状态码
根据库存不足时的不同情况来设置不同的状态码比如如果只是暂时性的库存问题使用 503 Service Unavailable如果是产品完全下架则使用 410 Gone可以在自定义异常类中添加逻辑如下在这个示例中chooseHttpStatus 方法基于 productDiscontinued 布尔变量的值来选择不同的HTTP状态码如果产品已经停产那么使用 410 Gone 状态码如果仅仅是暂时的库存问题则使用 503 Service Unavailable如此异常类的构造函数中传入的参数 productDiscontinued 决定了异常应该携带的HTTP状态码
