2

我的问题很简单。我们应该还是不应该在 Sling Models/WCMUsePojos 中处理/捕获异常？

细节：

我们有几个调用 OSGi 服务方法的 SlingModels，当任何异常被抛出时，我们都会将其捕获到 SlingModel，然后我们在模型中进行 @PostConstruct 方法

slingHttpResponse.sendError(500);

这似乎对我们不起作用，响应状态是 500（在浏览器的网络选项卡中检查），但页面无论如何都会加载，而不是加载我们的 500.jsp 页面或设置的“内部服务器错误页面”。

事实上，对我们有用的是将异常重新抛出到默认处理程序。这成功地加载了 500.jsp 页面。

前任。

@PostConstruct // THIS WORKS
public void init() throws Exception{
   try{
     // Business Logic calling Injected OSGi Service Methods
   }
   catch(Exception e){
     // Log exception and rethrow
     LOG.error("Exception in Model",e);
     throw e;
   }
}

上述实现是否理想？这适用于下面的代码，它不适用于我们

 @PostConstruct  // THIS DOES NOT WORK PROPERLY
    public void init() throws Exception{
       try{
         // Business Logic calling Injected OSGi Service Methods
       }
       catch(Exception e){
         // Log exception and SEND ERROR
         LOG.error("Exception in Model",e);
         slingHttpResponse.sendError(500);
       }
    }
4

1 回答 1

2

在普通页面中，大多数 SlingFilter 甚至 HTL 本身都会多次包装请求和响应对象。许多这些实现只是获取响应的输出，而忽略其余的（例如 http-header、状态代码、请求属性，...）。

如果你做一个简单的测试（通过渲染你的组件），你会发现这两种方法都有效。如果您在一个普通的核心组件页面中执行此操作，那么您仍然会得到 500，但页面和组件已经呈现。

你必须例外。缺点是，它可能会将内部结构暴露给最终用户。这是一个重大的安全风险。

但请查看 AEM Commons 的“组件错误处理程序”。根据运行模式，它可以用另一个 HTML 片段替换组件。

https://adobe-consulting-services.github.io/acs-aem-commons/features/component-error-handler/index.html

于 2019-10-08T06:59:45.010 回答