Mastering C + + Builder Art of debugging (1)

First-Correct writing code

1. Introduction

2. Write Clean code

3. Use of exceptions and exception handling capabilities

4. Use of records (logging) mechanism

5. Using recording mechanism and class exception handling mechanism

6. Handling exceptions that occur outside your code

7. Your turn

8. Copyright Notice

Brief introduction

This article, I will start from the most basic beginning. But hopefully it can involve a broader dimension, not just your program debugging (Debug). You will see that I think the whole meaning of the word error (debugging) is not just run through the IDE's built-in mechanism. I hope that at the end of this little article, almost every reader will be able to learn at least a new thing and hide it in your arsenal. Keep in mind that the less bugs you have in your program, the better your end users will feel about your program, and the better you can handle bugs, and the more likely users will be to tell you when they find bugs. OK, now fasten your seatbelt and put on your goggles, let's start a crazy journey!

Write Clean code

First and perhaps the most important point is that writing clean, readable code is extremely important. Being able to review a piece of code and annotate it to explain what this piece of code does and why it will save you countless painful hours of tracking code later. Maybe you'll spend a little more time writing, but when you spend n hours tracking the elusive bugs, you'll agree to spend more time making the program code readable. (You could have done it easily). If you have not done so, I suggest you stop and read another Scott's wonderful article-the style of the code (translated as soon as you need it).

Using exceptions and exception handling capabilities

Now go to the next step, which is still a code based procedure. (except in rare cases, you can't always use a system-built debugger, so it's always a good idea to know other bugs that can find these problems). This step is all about how to do it, and more importantly, the error that the system throws to you when the form is abnormal. In the dark old days before the C + + standard was recognized, an application usually emits an error signal by returning a value (this method is still used in OLE and some WINAPI functions). Obviously, you can easily ignore these (in fact, often, I mean, do you often check the return value of a WINAPI function?). ）。

So they decided ..., okay, we need a new mechanism, one you can't ignore. But you can handle that customization (custom customize). The anomaly appears. Want a special type of error flag? It's easy to define a new exception type (just a class, nothing else), throw it (produce this exception). Finished.

Example:

class myexception
{
public:
　　　　　　　  ansistring imessage;
　　　　　　　  myexception(ansistring message) { imessage=message;}
};

throw new MyException ("Test exception message");

It's that simple! (Not very completely, of course, I'll add it soon). Beautiful and simple, and very easy to customize to meet your needs. Okey, you will ask: "I can produce anomalies, but how do I deal with them?" I mean, I want to exclude the exception from my code in the first time (position)! "It's easy to do, and it's actually easy to customize," he said. The standard committee defines the try {/* code */} mechanism, which, like the exception mechanism, can be customized to suit your needs! Just place your execution snippet in the Try module, and you'll need a catch () or __finally module to tell the program what to do if it gets an exception. Now is the benefit of doing so, you define a class type and enter variables to catch exceptions-by declaring catch (). (In the previous example, this should be the case-catch (myexception &e) {/* * Here Write the processing code to catch the Exception/}) in order to make this system more powerful, you can build a complete subclass inheritance tree. So that when you capture the base class, you can catch all the exception types that inherit from the base class (a good example in VCL is that all the exceptions are inherited from the exception class, so catch (exception& e) catches all the VCL exceptions, Of course the package also includes what you generate. Except for Esocketerror, see Xiphias in http://www.bytamin-c.com/howto (if you don't like E, I will translate as soon as possible). Remember this idea and I will elaborate on another step in the future. To make it a little more forceful, the standard Committee decided to include the following declaration catch (...), yes, there are three points in parentheses. This declaration allows us to catch any exception, I mean all the exceptions. You want to be a little more forceful? Of course, you can use the additional catch () declaration, with the IF. else If ... Looks pretty much the same. Here to remember! If you catch an exception type, then it will not be captured again! So let's look at the code below ...

try
{
　　　　　　　  // 程序的正常运行代码
}
catch(edbengineerror &e)
{
　　　　　　　  // 处理基于数据库引擎的错误
}
catch(eexternalerror &e)
{
　　　　　　　  //通常处理基于windows的错误
}
catch(exception &e)
{
　　　　　　　  // 处理所有其他的vcl错误
}

You can see here, according to "is Edbengineerror?" is-> processing, not?-> continue to capture "" is Eexternalerror? is-> processing, not?-> to continue the next capture "and so on ... In such an orderly order.

And then there's more. If you want to do something about an exception and don't want the exception to disappear, you can throw the exception back. It will continue to look backwards for the new catch () process to handle it. I can't say I do that often. But it's best to know, just as simple as "throw". In this way, throw will take the exception that has already been handled by you to find another catch to handle it.

Last but not least (this part is not included in the standard specification, but more like the Borland proprietary version) is the __finally declaration, using a __finally{} module, you can specify the code that will run regardless of whether any exception is generated. Here is the easiest place to clear the local variables you assign through the new method and reset all the flags that should be set back to normal (for example, to reset the mouse pointer in a waiting state to a normal state).

Yuck, too much! Take a break and have a moment to look at the exception class in the C++builder help (all e-start, you'll notice that they're all inherited from the exception class.) This is also a good practice for customizing your own exception classes! When you come back, we will enter the next journey.