明确提出系统范围错误的概念 [英] Concept to rise unambiguously system wide errors

查看:70
本文介绍了明确提出系统范围错误的概念的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好。



我实际上是在C ++嵌入式项目中工作,但对我们系统范围的错误处理实现不太满意。由于我们系统的有限性,编译器确实支持try / catch。



所以我正在寻找的是一个良好的实践概念,可以明确地提高系统范围的错误。



你们中有些人已经证实了实施吗?



感谢您的支持!

解决方案

好的,我没有现成的完整解决方案。我的瑞萨单核心控制器仍然必须在帖子中,但我可以描述我采用的方法。

我每个模块有一个错误表,它本质上是结构的静态数据数组: -



静态sError ErrorTable [] =

{

{ERR1,带有{0}插入的错误描述字符串,1 ,0,0,0,0},

{ERR2,{0} {1} {2}的另一个错误,3,5,7,0,0},
};



在我的情况下,一些参数实际上是函数的附加内容,用于调用以收集错误信息。



这意味着管理错误列表,但仅限每个模块。



对于每个线程,我然后在堆栈上放置一个CErrorHandler对象某些线程在线程运行时仍然存在的线程的开头附近。



在每个可以引发错误的点上,正在构建的代码被构建到某些内容中模块我们将调用M1,因此需要访问M1错误表。我这样做有点不同但基本上所有你需要的是ErrorTable是一个模块范围全局变量并且总是被称为ErrorTable,MACRO或函数调用在引发错误时可以只引用& ErrorTable并且它总是得到M1错误表。



当在运行时命中RaiseError时,代码在线程T1上运行,因此它在线程T1中查找CErrorHandler,并传递& ErrorTable和引发的错误号。剩下的很大程度上取决于你想要什么样的错误以及你想如何处理它们。

''查找线程T1的CErrorHandler'位可以简单或棘手地依赖于如何线程化适用于您的操作系统以及是否有线程本地存储。我有一个漂亮且有希望的便携式解决方案,这个叫做飞行器,可以在我的旧文章中找到

这里



只是一个粗略的轮廓,但我希望其中一些有用。

Hi you all of the community

I am actualy working in an C++ embedded project, but not very happy with our system wide error handling implementation. Due to limited ressouces of our system, the compiler does support try/catch.

So what I am looking for is a good practice concept to rise unambiguously system wide errors.

Do some of you have a proven implementation?

Thanks for your support!

解决方案

OK I don''t have an off the shelf complete solution for you. My Renesas single core controller must still be in the post but I can describe the approach I take.
I have one error table per module which is essentially a static data array of structs:-

static sError ErrorTable[] =
{
{ ERR1, "Error desription string with {0} inserts", 1, 0, 0, 0, 0 },
{ ERR2, "Another error with {0}{1}{2}", 3, 5, 7, 0, 0 },
};

In my case some of the parameters are actually addreses of functions to call to collect the error information.

This does mean managing an error list but only per module.

For each thread I then place a CErrorHandler object on the stack at or near the start of the thread which remains in existance while the thread runs.

At each point where an error can be raised the code being built is being built into some Module we''ll call M1 and therefore needs to access the M1 error table. I do this a little bit differenly but essentially all you need is ErrorTable to be a module scope global variable and always called ErrorTable, the MACRO or function call at the point of raising the error can then just refer to &ErrorTable and it will always get the M1 error table.

When a RaiseError is hit at runtime the code is running on thread T1 so it looks up the CErrorHandler for thread T1, passing the &ErrorTable and the error number being raised. The rest is largely up to what kinds of errors you want and how you want to handle them.
The ''looking up the CErrorHandler for thread T1'' bit can be simple or tricky depeneding on how threading works in your OS and whether you have Thread Local Storage. I have a nifty and hopefully portable solution to this called ''Flyers'' which can be found in an old article of mine
here

Only a rough outline but I hope some of that was helpful.


这篇关于明确提出系统范围错误的概念的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆