我有以下简单的情况突然出现在这个地方.大量请求带有如下功能签名的设备：
- Err execute( const ICommandContext &context,const RoutineArguments &arguments,RoutineResults &results)
基本上有一个请求处理服务器,它将调用它来执行具有这些签名的各种请求类型的函数.在出错的情况下,我们有2条返回路径.
> Err输出类型(认为它等同于int),用于通知服务器或系统出现与系统有关的问题,而不是请求.在处理用户请求之前,始终将其排序在函数顶部.
> RoutineResults提供了一个setStatus函数,可用于将请求的失败信息返回给客户端.
出于这个原因,我们有很多这种类型的代码弹出：
- // Failure due to request
- Err error = someFunctionCall(clientInput);
- if (!error.success()) {
- results.setStatus(error); // Inform the client of the error
- return SUCCESS; // Inform the system that we are all good
- }
我们有一个特定的请求类型,它有大约15个参数进入并在系统周围发送.如果错误设置似乎浪费,我们在概念上需要15个.如果我们需要通过并改变我们返回的方式,它也容易出错.我们如何有效地委托setStatus并返回只需要在函数中发生一次的少量代码？
宏观解决方案
一个c系统可以用宏来解决这个问题,例如：
- #define M_InitTry Err error
- #define M_Try(statement) if (!(error = statement).success()) { goto catch_lab; }
- #define M_Catch catch_lab: if (!error.successs())
- #define M_Return return error
哪个会像这样使用：
- Err execute( const ICommandContext &context,...) {
- M_InitTry;
- ...
- M_Try(someFunctionCall(clientInput));
- M_Try(someFunctionCall(otherClientInput));
- ...
- M_Catch {
- // Other specific actions for dealing with the return.
- results.setStatus(error);
- error = SUCCESS;
- }
- M_Return;
- }
这很好地清理了代码,但对goto并不是特别好.如果定义goto可能跳过的变量,则会导致问题.
委派解决方案
我试图考虑更多的C,所以我认为RAII类型的代表可能有所帮助.就像是：
- class DelegateToFunctionEnd {
- typedef std::function<void(void)> EndFunction;
- public:
- DelegateToFunctionEnd(EndFunction endFunction) : callAtEnd(endFunction) { }
- ~DelegateToFunctionEnd() {
- callAtEnd();
- }
- private:
- EndFunction callAtEnd;
- };
非常简单,它通过在析构函数中实现操作返回函数来执行操作的委托.您可以像这样使用它：
- Err execute( const ICommandContext &context,...) {
- Err error;
- DelegateToFunctionEnd del(std::bind(&RoutineResults::setStatus,&results,std::cref(error)));
- error = someFunctionCall(clientInput));
- if (error) return SUCCESS;
- ...
- }
Live example.
这个解决方案似乎没问题,但有几个问题：
>目前尚不清楚发生了什么.
>错误地设置错误更容易.
>您仍然需要大量的if语句来处理回报.
>配置终止操作的能力不是很好.
>如果用户在功能返回时未仔细考虑物品的销毁顺序,则会造成危险.
更好的解决方案？
这必定是经常出现的问题.是否有一个通用的解决方案提供了这个集合的干净委托并返回类型操作？
我在下面有一些不幸的限制.不要让这些阻止你回答,因为它可能对未来的人有所帮助.
>我正在研究c 03限制系统.我们有提升,但没有c 11.
>嵌入式系统,我们对异常和内存分配有愚蠢的规则.
