如何配置Logic Apps HTTP触发器异常处理，捕获失败并发送邮件

遇到这种情况太常见了——只靠状态码判断确实覆盖不了主机名解析失败这类连接级错误，我给你一套靠谱的实现思路，分四步走：

1. 用Scope打包HTTP请求逻辑 #

首先把你的HTTP请求操作放进一个**Scope（作用域）**里，命名比如「执行核心HTTP请求」。这么做的好处是能把所有需要监控的逻辑打包，后续统一处理所有错误场景，不用单独给每个操作加错误处理。

2. 处理非200状态码的业务失败 #

在Scope内部，HTTP请求之后加一个条件判断：

• 条件规则：检查HTTP请求返回的状态代码是否不等于200
• 如果条件成立（比如返回404、500这类错误码），添加一个「终止」操作，设置终止类型为失败，自定义错误消息比如HTTP请求返回非成功状态码：@{body('HTTP')?['statusCode']}。
  这样一来，哪怕HTTP请求本身执行成功了，但只要状态码不符合预期，我们就主动把整个Scope标记为失败，和连接错误统一处理。

3. 配置邮件通知的触发规则 #

在Scope外面添加发送邮件的操作（比如Office 365 Outlook的「发送邮件」），重点是修改这个邮件操作的Run After属性：

• 默认情况下，邮件只会在Scope成功时运行，你要改成勾选Failed、TimedOut、Canceled这三个状态。
  这样不管是主机名解析失败导致Scope直接失败，还是非200状态码触发的主动终止失败，都会触发邮件通知。

4. 优化邮件内容，方便排查 #

邮件里可以带上详细的错误信息，帮你快速定位问题：

• 比如添加错误状态：@{result('执行核心HTTP请求')[0]['status']}
• 错误详情：@{result('执行核心HTTP请求')[0]['error']['message']}
• 甚至可以把整个Scope的执行结果拼接进去：@{join(result('执行核心HTTP请求'), '; ')}

为什么原来的方法会挂起？ #

你之前只判断状态码等于200，但主机名解析失败属于操作级别的异常——这时候HTTP请求根本没执行成功，后续的条件操作默认只会在HTTP请求成功时才运行，失败时完全不会触发，导致流程卡在那里挂起。而用Scope+Run After的方式，能覆盖所有失败场景，包括操作异常和业务逻辑异常。

内容的提问来源于stack exchange，提问作者AlHal