python - 使用 Python Lambda 处理 AWS Step Function 中的意外错误的最佳实践是什么？

Question

Step Functions是控制 lambda(或其他事件)流的 AWS 结构。我所有的 lambda 都使用 Python(但 Lambda 可以使用大多数主要语言)。在整个过程中，我的 step 函数将状态更新发送回客户端(客户端通过 API 触发它)。假设它通过这些更新进行:开始 -> 进行中 -> 完成 -> 完成。对于已处理的错误，它会将“错误”状态发送回客户端。所以客户端可以看到这样的时间线:开始 -> 进行中 -> 错误。这是理想的 - 因此用户知道该过程已停止。
但是当出现意外/未处理的错误时，客户端永远不会真正知道，时间线可能会无限期地停留在“进行中”——用户不知道发生了什么。所以我开始调查 built-in Step Function error handling .我喜欢这个选项，因为我可以为每个 lambda 或事件创建一个“捕获”函数，如果出现错误，我可以在其中与客户端进行通信。这样做的缺点是它确实使阶跃函数模板/设计变得困惑，请参阅下面的前/后屏幕截图。
前 - - - - - - - -

后 - - - - - - - -

生成这些图形的模板代码看起来也好不到哪里去。所以我考虑了一个看起来同样困惑的替代方案。我可以在整个 lambda 的每个 lambda 中添加一个 try/except 块 - 以捕获任何/所有错误。例如:

def lambda_handler(event, context):
    try:
        #Execute function tasks
    except:
        #Communicate back to client that there was an error

类似于 step 函数“Catch”函数，这将确保我捕获并传达任何错误。但这似乎是一个坏主意，因为它是什么(添加毯子/盲目尝试/除外)。
所以现在我被困在凌乱/重复的代码和尝试/排除一切之间。我是否错误地实现了步骤功能“Catch”？我是否错过了处理未知 Python 错误的更好方法？完全有另一种方法吗？

Answer 1

正如@stijndepestel 指出的那样，进行全面错误检查是个好主意。
我在 Python Lambda 函数中所做的是:我有一个自定义路由器类，除了路由管理之外，它还处理所有错误。如果错误继承自我创建的基本错误类，那么它是我抛出的自定义错误，并且在我创建它们时分配了特殊信息，当它们转换为字符串时会自动格式化。如果可能，路由器将其发送回客户端。
但是，如果错误是未知/意外错误，则路由器会将尽可能详细的信息打印到 CloudWatch Logs，然后向客户端返回一条通用的“500 Internal Server Error”消息。
我可能会在将来设置它，以便在发生此类错误时通过电子邮件或类似方式通知我，以便我可以快速采取行动。