我正在开发 Web 服务，并且对超时/异常处理方法有疑问。
我有一个 web 服务 (WS1) 和一个客户端 C。客户端从用户接收一些操作并调用 WS1 进行一些不需要向用户提供响应的操作。
我可以通过 2 种可能的方式设计应用程序中的错误处理 -
从C调用WS。如果调用成功，WS会返回一个token。如果 C 出于任何原因（可能是 WS 中的故障或网络超时）没有获得令牌，它将存储在数据库中，并且某些作业将在稍后重试该操作。
从 C 调用 WS 并结束帖子。如果有任何问题，WS 将 ping 回 C（在单独的调用中）。如果没有 ping 回，则假设事务已通过。
一般来说，有哪些选项可以确保 WS 调用成功。如果事务在第一次尝试中失败，有哪些方法可以重试操作？
这两种方法都是有效的。你所拥有的只是一个同步操作和异步操作。例如，sockets 这两种模式都可以使用多年；例如文件读取功能也是如此。
选择归结为这一点 - 您的客户端程序是否有能力等待操作完成。如果可以，同步操作更易于编程。否则使用回调做异步模型。
就重试而言 - 这又取决于。重试多长时间？许多程序只是在失败时循环尝试 2-3 次。如果您的重试是在特定时间后重试的类型，那么您必须在某处存储有关您尝试执行的操作的信息。那个地方可能是程序内存，或者一些永久存储。同步和异步模式都需要用于重试的信息存储。异步更是如此，因为当您收到回电时，您需要检查您的商店以找出您正在尝试做什么。在同步模式下，信息多次隐式存储在程序堆栈中，用于数据变量中。
那么重试也应该在程序崩溃中幸存下来吗？如果是这样，那么您需要将信息存储在某个离线商店中。我曾经有一个电信应用程序；该电信应用程序会将呼叫详细记录写入数据库。如果由于某种原因失败，程序会简单地将 CDR 写入本地文件，然后继续。一个 cron 作业将通过将本地文件中的记录发送到数据库来清理它们。这样，提供计费信息的通话记录即使程序崩溃也能幸免于难。
有些人使用消息队列来做这样的事情。消息队列提供有保证的传递。客户端发送消息。服务器端得到它。仅当服务器能够成功处理消息时，服务器才会从 Q 中删除消息。否则消息会保留；这里的危险是消息可能有一些永久性的失败，然后它会进入一个无限循环。
由于某些永久性故障（例如向 WS 提供错误参数）而陷入无限循环，无论如何都是您必须处理的事情。