使用lua的error（..，level）是一种反模式吗？

在Lua中使用error()“向上冒泡”错误非常不常见。更常见的是返回nil，然后跟随一个描述错误的字符串，让调用者决定函数是否失败，是否可以恢复以及是否应该重试等等。

这也更具有性能，因为它比调用error()少了一些额外的开销（它只是一个普通函数调用）。

过度使用pcall和转发错误是一个非常糟糕的想法。这只会使你的代码更难以跟踪。

返回错误级别是否成问题？只是将一个数字扔进去然后希望它正确似乎很不专业。

并不会有问题，除了会造成混淆。错误信息是为了帮助解决问题的，如果你漫不经心处理错误，那么它们也就无法帮到你了。从实现的角度来看，这种做法没有风险：luaB_error 使用 luaL_where 来添加错误位置相关信息。如果你传入了错误的级别，这些信息也就只是被简单地忽略了：

function foo ()
   error("where am I", 7)
end
foo() -- lua: where am I
      -- stack traceback: ...

通常我只看到过级别为 1 和 2 的错误，后者通常用于指示传递给函数的参数无效。但这只是我的经验，没有什么数据支持。

至于剩下的问题，主要还是基于个人意见的。使用任何适合你和你的问题的方法。error() 和 nil 加信息两种方式都是有道理的。你在调研方面做得很好，看起来已经足够理解并且可以自行决定了。

首先，您需要区分由于错误的API调用和代码中的实际错误而导致的错误。

如果“error”调用的目的是告诉API用户他们传递了错误的参数，则应该在每个API函数中验证参数，以便错误级别可知，并且您的库的其余部分知道它正在使用有效的参数。如果最终得到一个复杂的验证函数层次结构，它们可以为函数名称和错误级别传递参数。以下是一个非常人为的示例，说明如何使用错误级别：

local function lessThan100(x, funcName, errorLevel)
  if x >=100 then
    error(funcName .. ' 需要小于100的数字', errorLevel)
  end
end

local function numLessThan100(x, funcName, errorLevel)
  if type(x) ~= 'number' then
    error(funcName .. ' 需要数字', errorLevel)
  end
  lessThan100(x, funcName, errorLevel + 1)
end

-- API函数
local function printNum(x)
  numLessThan100(x, 'printNum', 3)
  print(x)
end

如果“error”调用表示代码中的错误，则不要使用级别，因为您无法知道何时会触发错误。

这似乎是一个为特定目的而存在的特定工具的例子。根据文档：

错误函数有一个额外的第二个参数，它指定了应该在哪个级别上报告错误。你可以责备别人犯的错误。例如，假设你编写了一个函数，它的第一个任务是检查它是否被正确调用：

然后，有人使用错误的参数调用了你的函数：

Lua将指向你的函数 - 终究是foo调用了error - 而不是指向真正的罪魁祸首，调用者。 要纠正这个问题，你需要告诉error，你正在报告在调用层级结构中发生的错误是在第二个级别上发生的（第一个级别是你自己的函数）。

没有一个语言是完美的，有时设计者会为了解决一个特定的问题而创建一个强大而潜在危险的工具。（例如C＃的反射）在这种情况下，看起来意图是在做出调用的函数中报告错误的不良API调用，而不是在接收它的函数中。因此，根据文档，级别1和2是唯一的预期级别，但这并不意味着其他用例不存在。

你已经强调了（误）使用这个语言特性可能会引起比它解决的问题更多的问题（即用一个不合理的错误代码误导用户）。好的做法问题通常相当主观，但我们的工作是编写良好，可维护，无漏洞的代码，无论使用何种语言。语言设计师显然认为在你的工具箱中放置这个工具是一个好主意。你可以从手册开始阅读，但除此之外，你需要理解这个工具，并善加利用。如果你觉得这个工具不应该存在，或者你只是不感到舒适使用它，那么就坚持使用你提到的另一种替代方法。