asynchronous函数应该永远抛出?

我写了一个有许多asynchronous函数的库。 如果其中一个参数是错误的,则SYNCHRONOUS帮助器函数将引发错误:

proto.makeParameters= function( filters ){ default: throw( new Error("Field type unknown: " + fieldObject.type ) ); break; } 

在我的asynchronous函数中,当我使用它时,我有:

 proto.someAsyncFunction = function( cb ){ // Run the query try { var parameters = this.makeParameters( filters ); } catch( e ){ return cb( e ); } } 

所以:

  • asynchronous函数永远不应该抛出? (就像我做的那样)

  • 现在,我正在捕捉所有的错误。 我更挑剔吗? 也许组成一个错误types,只是检查? 如果是这样的话,我应该怎么做?

你对asynchronous代码的假设是正确的。 关于这个话题,请看Isaac Schlueter本人的这篇文章:

节点中的模式是同步方法抛出,asynchronous方法将错误作为第一个parameter passing给callback。 如果你的callback函数的第一个参数是falsey(通常是null或者undefined),那么世界一切都很好。

http://groups.google.com/forum/#!msg/nodejs/W9UVJCKcJ7Q/rzseRbourCUJ

asynchronous函数永远不会抛出是否是一个好习惯? (就像我做的那样)

当然,asynchronous函数会在我们不喜欢的时候抛出exception,只是因为软件不完善。 所以抛出自定义exception是完全正确的,但重要的是如何正确地捕捉它们。

问题在于与同步代码不同,asynchronousexception的堆栈可能不可用。 所以当发生exception时,并不总是可以说出在哪里返回控制,处理器在哪里。 node.js有两个方法来指定发生asynchronous代码时发生的exception: process uncaughtException和domains 。

正如你所看到的,asynchronous代码中exception的处理是非常棘手的,所以抛出一个exception应该被视为最后的select。 如果该函数只是返回操作的状态,它不是一个例外。

在我看来,在提供的代码片段中,exception被正确地引发,因为它表明该方法被错误地调用并且不能完成它的工作。 换句话说,错误是永久的。 这表明应该修复的应用程序存在严重缺陷。 但是如果函数不能创build一个可以修改应用程序就可以修复的临时原因的参数,那么返回状态是更合适的select。