可选的错误处理
我有一个如下所示的创建方法，我想在其中（如果返回是空指针）获取错误。但是，我希望此错误处理是可选的，而不是调用该函数的要求。
代码：
class foo {
foo() {...};
public:
~foo();
static foo* createFoo(int aparam = 42, int bparam = 10, int& error = ?) {
afoo* = new foo();
if (!afoo) {
error = 11;
return 0; //NULL
}
...
return afoo;
}
}
所以我可以决定使用：
foo* myfoo = createFoo(42);
if (!myfoo) { ... }
或者
int errorcode = 0;
foo* myfoo = createFoo(42, 10, errorcode);
...
此时（在我的真实代码中），我只是使用空指针（而不是引用）并在给出错误之前在 createFoo 代码中确定其有效性。
我感兴趣的是这种情况的最佳实践。
I have a create method as shown below, in which I want to (if the return is a null pointer) get the error from. However I want this error handling to be optional, and not a requirement in calling the function.
The code:
class foo {
foo() {...};
public:
~foo();
static foo* createFoo(int aparam = 42, int bparam = 10, int& error = ?) {
afoo* = new foo();
if (!afoo) {
error = 11;
return 0; //NULL
}
...
return afoo;
}
}
So I can then decide to either use:
foo* myfoo = createFoo(42);
if (!myfoo) { ... }
Or
int errorcode = 0;
foo* myfoo = createFoo(42, 10, errorcode);
...
At this point (in my real code), I am just using a null pointer (instead of a ref) and determining its validity in the createFoo code before giving it error.
My interest is in the best practice for this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道我可以提供最佳实践，但这是我的观点。
检查 NULL（分配失败）是 C 和 C++ 中的标准做法，它是一个很好理解且易于识别的习惯用法。添加可选错误代码在提供灵活性的同时也增加了可能不必要的复杂性。调用者需要决定是否使用该参数。
他们为什么要使用该参数，除非他们认为该参数可能在该位置失败？ 该怎么办
如果您觉得错误代码很重要， ？我建议使用替代签名，即您始终检查返回代码，而不检查返回指针的值：
这可能是一个不太方便的函数，但会将调用者（用户）推向正确的方向。
或者，您可以使用异常，要么确保抛出 std::bad_alloc，要么抛出您自己创建的带有适当错误代码的异常。这似乎是最简洁的签名：
我所追求的哲学是：最小化复杂性。在这种情况下，通过删除似乎是无关的选项。要么错误代码很重要并且应该始终使用，要么它是无关的并且总是被忽略。
I don't know that I can offer best practice but here is my perspective.
Checking for NULL (a failed allocation) is standard practice in C and C++, it is a well understood and easily recognized idiom. The addition of an optional error code, while providing flexibility also adds arguably unneeded complexity. It burdens the caller to decide whether they will use the parameter.
Why would they use the parameter unless they felt it was likely to fail in that location? How would
If you feel the error code is significant. I would suggest the alternate signature, whereby you always check the return code, and do not check the value of the returned pointer:
This is a perhaps less convenient function, but nudges the caller (user) in the right direction.
Alternately, you could use exceptions, either ensuring std::bad_alloc is thrown, or throwing an exception of your own creation with the appropriate error code. This would seem to be the cleanest signature:
The philosophy I am driving at is: minimize complexity. In this case by removing what seems to be an extraneous option. Either the error code is significant and should always be used, or it extraneous and will always be ignored.
当您通过引用传递某些内容时，您是在告诉该函数的用户这是必需的参数。如果您想让错误代码可选，请传入一个指向 int 的指针并将其默认值设置为 null。
When you pass something by reference, you are telling the user of that function that this is a required parameter. If you want to make the error code optional, pass in a pointer to an int and set its default value to null.