异常处理和重构问题...... [英] Exception Handling and Refactoring Question ...
问题描述
我正在用C ++编写一个模拟软件包，到目前为止我已经写了一些关于
8000行代码的文章30班。到目前为止，我还没有使用C ++
例外（出于各种原因）。只有两个资源我使用
是内存和文件I / O以及每当有内存分配时
失败或文件I / O失败我只是简单地调用自定义断言类型
函数检查，打印错误信息并中止。现在看起来好了
（用于模拟器基础开发），但是当我开始向模拟器编写
a GUI时，我需要更优雅的方式来处理
这样的特殊情况。
现在，我正在阅读有关C ++异常处理的所有好处和
我正在考虑重构我的代码使用try-catch类型异常
处理。同意，我应该在开始之前考虑过这个问题
编写一行代码（我的编程技巧要低得多）
然后） - 但现在我已经到目前为止，是否值得进行
重构？，或者甚至可能没有完全重新设计
一切？ （因为我已经在很多地方读过异常处理
应该与整体设计紧密结合）。我的另一个选择是
扩展自定义断言类型的功能，不仅仅需要
显示错误信息并中止。
我们将非常感谢任何建议，指示或参考。
谢谢，
Vijay。
-
PS（阻火）：我的身份C ++大师与我最喜欢的
专辑木偶大师有关而不是我对C ++的熟练程度。
Hi,
I am writing a simulation package in C++, and so far I''ve written about
8000 lines of code and have about 30 classes. I haven''t used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.
Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I''ve come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I''ve read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.
Any suggestions, pointers or references will be greatly appreciated.
Thanks,
Vijay.
--
PS (flame-guard): My id "Master of C++" has more to do with my favorite
album "Master of Puppets" than with my proficiency in C++.
推荐答案
Master of C ++ <毫安************* @ gmail.com>在消息中写道
news：11 ********************** @ o13g2000cwo.googlegr oups.com ...
"Master of C++" <ma*************@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
我正在用C ++编写一个模拟软件包，到目前为止我已经写了大约8000行代码并且有大约30个类。到目前为止，我还没有使用C ++
异常（出于各种原因）。只有两个资源我使用
是内存和文件I / O，每当有内存分配
失败或文件I / O失败时我只需调用自定义断言类型
函数进行检查，打印一个错误消息并中止。现在这似乎没问题（对于模拟器基础开发），但是当我开始向模拟器编写GUI时，我需要一种更优雅的方式来处理这种异常情况。
现在，我正在阅读有关C ++异常处理的所有好处，并且我正在考虑重构我的代码以使用try-catch类型异常处理。同意，在开始编写单行代码之前我应该考虑过这个问题（我的编程技巧非常低劣） - 但是现在我已经走到了这一步，是否值得进行重构？，或者甚至可以在没有完全重新设计的情况下完成任何事情？ （因为我已经在许多地方读过异常处理
应该与整体设计紧密结合）。我的另一个选择是扩展自定义断言类型功能，而不仅仅是显示错误信息并中止。
任何建议，指针或参考都会大大增加赞赏。
谢谢，
Vijay。
-
PS（阻火）：我的身份C ++大师与我最喜欢的专辑木偶大师有关。而不是我对C ++的熟练程度。
Hi,
I am writing a simulation package in C++, and so far I''ve written about
8000 lines of code and have about 30 classes. I haven''t used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.
Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I''ve come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I''ve read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.
Any suggestions, pointers or references will be greatly appreciated.
Thanks,
Vijay.
--
PS (flame-guard): My id "Master of C++" has more to do with my favorite
album "Master of Puppets" than with my proficiency in C++.
我建议您使用ASSERT来解决错误，这些错误只能由
编程错误和错误异常引起这可能是由于
不正确的用户输入引起的。 ASSERT的重点是帮助您进行
软件测试。由于它在生产代码中丢失，因此对最终用户来说没有用。
。异常编程可以用来促进自动恢复（在关键任务应用程序中很难但很有必要），或者只需要
来制作好的错误消息 - GEM （更容易）。
您提到的资源就好像它们是唯一的错误来源，但是我见过的任何有用的软件都容易受到不正确的用户输入的影响。例外
可能是处理这个问题的好方法，但是相当多的想法必须进入它b
。如果你的目标只是创业板，你必须问自己，你的最终用户是否能根据你给出的
消息弄清楚他做错了什么他。我希望我使用的某些软件的程序员已经考虑过这个了。
一个控制台模式程序，它只适用于GEM看起来像这样：
int main（）
{
试试{
start_running（） ;
} catch（std :: exception& e）{
std :: cerr<< e.what（）<< ''\\ n'';
}
}
只需从std :: exception派生所有异常类这是
吧！原则上你不需要在整个
程序中编写任何其他试块。不能比那简单得多。
Google用于按合同编程看看有关
组织ASSERT编程的一些有趣想法。
HTH
-
Cy akaMastered by C ++
http://home.rochester.rr.com/cyhome/
Cy Edmunds写道：
Cy Edmunds wrote:
你提到资源就好像它们是唯一的错误来源，但我见过的任何有用的软件都容易受到不正确的用户输入的影响。例外
可能是处理这个问题的好方法，但必须考虑相当多的想法。如果你的目标只是创业板，你必须问自己，你的最终用户是否能够根据你给他的消息弄清楚他做错了什么。我希望我使用的某些软件的程序员已经考虑过这个了。
一个专为GEM设计的控制台模式程序看起来像这样：
int main（）
{
start_running（）;
} catch（std :: exception& e）{
std :: cerr<< e.what（）<< ''\\ n'';
}
只是从std :: exception派生所有的异常类，这就是它！原则上，您不需要在整个
程序中编写任何其他试块。不可能比这简单得多。
You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.
A console mode program which was just going for GEMs would look like this:
int main()
{
try {
start_running();
} catch (std::exception &e) {
std::cerr << e.what() << ''\n'';
}
}
Just derive all of your exception classes from std::exception and this is
it! In principle you don''t need to write any other try blocks in the entire
program. Can''t get much simpler than that.
如果你打算使用标准的库异常类，那就是它们的意图
，然后在
程序的环境中发生的错误，例如用户错误，设备I / O错误或资源错误，
应该来自std :: runtime_error，而不是std :: exception。逻辑
传统上由断言表示的类型的错误应该从std :: logic_error派生出来（如果你想为此使用异常）。我想
期望主要在图书馆代码中发现这种异常
意图广泛重用并且必须执行参数验证
断言。
Gregg
If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_error, not std::exception. Logic
errors of the type traditionally represented by assertions should derive
from std::logic_error (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and must perform parameter validation
without asserting.
Gregg
Cy Edmunds写道：
Cy Edmunds wrote:
你提到的资源就好像它们是唯一的错误来源，但我见过的任何有用的软件都容易受到错误的用户输入的影响。例外
可能是处理这个问题的好方法，但必须考虑相当多的想法。如果你的目标只是创业板，你必须问自己，你的最终用户是否能够根据你给他的消息弄清楚他做错了什么。我希望我使用的某些软件的程序员已经考虑过这个了。
一个专为GEM设计的控制台模式程序看起来像这样：
int main（）
{
start_running（）;
} catch（std :: exception& e）{
std :: cerr<< e.what（）<< ''\\ n'';
}
只是从std :: exception派生所有的异常类，这就是它！原则上，您不需要在整个
程序中编写任何其他试块。不可能比这简单得多。
You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.
A console mode program which was just going for GEMs would look like this:
int main()
{
try {
start_running();
} catch (std::exception &e) {
std::cerr << e.what() << ''\n'';
}
}
Just derive all of your exception classes from std::exception and this is
it! In principle you don''t need to write any other try blocks in the entire
program. Can''t get much simpler than that.
如果你打算使用标准的库异常类，那就是它们的意图
，然后表示在程序环境中出现错误的异常类，例如用户错误，设备I / O
错误或资源错误，应该来自std :: runtime_error，
不是std :: exception。代表传统上由断言表示的
类型的逻辑错误的异常类应该来自
std :: logic_error（如果你想为此使用异常）。我想
期望主要在图书馆代码中发现这种异常，这是因为广泛重用并且必须执行参数验证的
没有断言。
Gregg
If you are going to use the standard library exception classes the way
they were intended, then exception classes representing errors that
occur in the environment of the program, such as user errors, device I/O
errors, or resource errors, should be derived from std::runtime_error,
not std::exception. Exception classes representing logic errors of the
type traditionally represented by assertions should derive from
std::logic_error (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and which must perform parameter validation
without asserting.
Gregg
这篇关于异常处理和重构问题......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
