如何用IcedCoffeeScript正确处理错误？

Question

在 node.js中，通常的做法是将错误消息作为回调函数的第一个参数返回。在纯JS中有许多解决方案（promise，步骤，seq等），但它们似乎都无法与ICS集成。在不损失太多可读性的情况下处理错误的正确解决方案是什么？

例如:

# makes code hard to read and encourage duplication
await socket.get 'image id', defer err, id
if err # ...
await Image.findById id, defer err, image
if err # ...
await check_permissions user, image, defer err, permitted
if err # ...


# will only handle the last error
await  
  socket.get 'image id', defer err, id
  Image.findById id, defer err, image
  check_permissions user, image, defer err, permitted

if err  # ...


# ugly, makes code more rigid
# no way to prevent execution of commands if the first one failed
await  
  socket.get 'image id', defer err1, id
  Image.findById id, defer err2, image
  check_permissions user, image, defer err3, permitted

if err1 || err2 || err3  # ...

Answer 1

正如IcedCoffeeScript知识库第35期所讨论的，还有另一种基于ice风格连接器的技术，这些连接器是将回调/延迟作为输入，并返回另一个回调/延迟的函数。

假设您的项目有一个标准的回调参数顺序：第一个参数总是错误，成功时为空。此外，进一步假设您希望在出现错误的第一个符号时保留函数。

第一步是制作一个连接器，我称之为“错误短路器”或“ESC”：

{make_esc} = require 'iced-error'

其实现方式如下：

make_esc = (gcb, desc) -> (lcb) ->
    (err, args...) ->
        if not err? then lcb args...
        else if not gcb.__esc
            gcb.__esc = true
            log.error "In #{desc}: #{err}"
            gcb err

要了解它的作用，请考虑一个如何使用它的示例:

my_fn = (gcb) ->
    esc = make_esc gcb, "my_fn"
    await socket.get 'image id', esc defer id
    await Image.findById id, esc defer image
    await check_permissions user, image, esc defer permitted
    gcb null, image

这个版本的my_fn首先创建一个错误接收器（或esc），其工作是双重的：（1）用错误对象触发gcb;和（2）记录有关错误发生位置和错误内容的消息。显然，您应该根据您的设置改变确切的行为。然后，所有后续调用带有回调的库函数都将像往常一样通过 defer 生成回调，然后通过 esc 连接器运行，这将更改回调的行为。新行为是在出现错误时向函数调用 gcb 全局变量，并让当前 await 块在成功时完成。此外，在成功的情况下，无需处理空错误对象，因此仅填充后续插槽（如 id、图像和允许）。

这项技术非常强大且可定制。关键思想是，defer生成的回调实际上是连续的，可以改变整个程序的后续控制流。它们可以在一个库中实现这一点，因此您可以获得许多不同类型的应用程序所需的错误行为，这些应用程序调用具有不同约定的库。

Answer 2

我通过风格和编码约定来解决这个问题。而且它确实一直出现。让我们在下面把你的代码段，充实一点，以便我们有一个可行的功能。

my_fn = (cb) ->
  await socket.get 'image id', defer err, id
  if err then return cb err, null
  await Image.findById id, defer err, image
  if err then return cb err, null
  await check_permissions user, image, defer err, permitted
  if err then return cb err, null
  cb err, image

你完全正确，这很难看，因为你在许多地方短路了代码，你需要记住每次返回时调用cb。

您给出的其他代码片段会产生不正确的结果，因为它们会在需要序列化的地方引入并行性。

我个人的ICS编码约定是：（1）从函数中只返回一次（控制从末端掉下来）;（2）尝试在同一缩进级别处理所有错误。重写你所拥有的，以我的首选风格：

my_fn = (cb) ->
  await socket.get 'image id', defer err, id 
  await Image.findById id, defer err, image                   unless err?
  await check_permissions user, image, defer err, permitted   unless err?
  cb err, image

在套接字中发生错误的情况下。要获得调用，您需要检查错误两次，显然这两次都会失败。我不认为这是世界末日，因为它使代码更干净。

或者，您可以这样做:

my_fn = (autocb) ->
  await socket.get 'image id', defer err, id
  if err then return [ err, null ]
  await Image.findById id, defer err, image
  if err then return [ err, null ]
  await check_permissions user, image, defer err, permitted
  return [ err, image ]

如果您使用autocb，这不是我最喜欢的ICS功能，那么无论何时返回/短路函数，编译器都会为您调用autocb。根据经验，我发现这种构造更容易出错。例如，假设您需要在函数开始时获取一个锁，现在需要释放它n次。其他人可能不同意。

另一个注意事项，在下面的评论中指出。autocb的工作方式与back类似，因为它只接受一个值。如果您想像本例中那样返回多个值，则需要返回一个数组或字典。deer在这里执行解构分配以帮助您：

await my_fn defer [err, image]