`:warning-handlers`目前接受函数对象，而通过(cljs.main)调用时无法发送这些对象。
为了帮助构建工具，增强这些选项以支持通过`requiring-resolve`接受符号，在1.10中实现。这样，构建工具就可以引用类路径上的函数。
CLJS可以借鉴
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/server.clj#L263-L270
我认为:watch-fn和:watch-error-fn已经做得很好了，通过
https://github.com/clojure/clojurescript/blob/47386d7c03e6fc36dc4f0145bd62377802ac1c02/src/main/clojure/cljs/closure.clj#L80-L109
h4. 所需行为
现在，{{:warning-handlers}}编译器选项能够指定通过它们的完全限定命名空间符号的功能。例如，下面的{{cljs.edn}}中的{{compile-opts}}：
{:warning-handlers [some.namespace/warning-handler1
some.namespace/warning-handler2]}
如果这些警告处理器存在并且位于类路径上，将找到并解析警告处理器函数{{warning-handler1}}和{{warning-handler2}}。
h4. 分析
1. 如上所述，我们确实有以前的工作，用于解决编译器选项：{{:watch-fn}}，{{:watch-error-fn}}以及也{{:preprocess}}。
2. {{:warning-handlers}}在几个地方与{{\*cljs-warning-handlers\*}}绑定，但只从一个函数中：{{cljs.analyzer/warning}}。
3. 先前的作品使用私有的函数{{cljs.closure/sym->var}}进行解析。
h4. 方法
将{{sym->var}}函数从{{cljs.closure}}移到{{cljs.util}}，并使其公开，将{{load-mutex}}设为一个参数。
使用{{sym->var}}从{{cljs.analyzer/warning}}解析每个警告处理器。
h4. 测试
添加到{{cljs.analyzer-api-tests}}中的测试，以验证成功和符号配置错误的路径。
h4. 实施说明
1. 没有考虑自托管ClojureScript。
2. {{sym->var}}抛出{{:compilation}}阶段异常，我认为这对于警告处理器是合适的，鉴于选择：
https://clojure.org/reference/repl_and_main#_error_printing3. {{sym->var}}在`ex-info`的映射中包含相关的编译器选项关键字。但是... 在{{cljs.analyzer/warning}}中，我们处理的是{{\*cljs-warning-handlers\*}}的绑定，而不是编译器选项关键字。我假设从处理{{\*cljs-warning-handlers\*}}的{{cljs.analyzer/warning}}中的错误引用{{:warning-handlers}}是可以接受的。
h4. 观察
变量的使用有点奇怪，因为它在sym命名空间不存在时抛出异常，在sym未完全合格时也会抛出异常，但对sym无法解析的错误却默默忽略。这对我个人来说似乎有些对用户不友好。为此，我引入并使用了{{sym->var-checked}}来在sym未解析时代码抛出异常。可以单独创建一个ticket，考虑是否使用{{sym->var-checked}}来替换现有对{{sym->var}}的调用。
由于警告处理程序只有在{{cljs.analyzer/warning}}中解析，因此用户只有当发生警告时才会了解到配置错误。这根据您的观点可能是一个优点或缺点。也许从可能路径提前重复解析，即使只为更快地失败，也是有益的。也许从{{cljs.cli/load-edn-opts}}？
