• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            sherrylso

            C++博客 首頁 新隨筆 聯系 聚合 管理
              18 Posts :: 0 Stories :: 124 Comments :: 0 Trackbacks
            不知道大家是否有同感,在開發軟件應用系統的過程中我們經常面臨一個非常tedious的問題,即如何分類和處理軟件行為產生的錯誤值,大致有這樣幾個方面的問題:
                    第一.錯誤值如何分類。參考microsoft的開放文檔,按照錯誤值的嚴重程度分為critical、error、warning、information等四個級別。
                    第二.錯誤值如何在各個軟件子模塊中有效的表示和溝通。
                    第三.如何劃分出用戶所關心的錯誤值集合。
            這篇文章對錯誤類型定義與處理作了很好的闡釋。推薦給大家,大家如果有什么好的開發經驗,歡迎探討。
            FYI:
            Taxonomy of Error Types and Error Handling
            Posted: Jun 21, 2007 8:13 PM

            Most of what is written about error and exception handling is fairly abstract and vague. When specific recommendations are made, those usually consist of examples given for specific circumstances. Yet, error handling is a fundamental task for developers. This brief review attempts to categorize the different types of error conditions a program can encounter. By describing these categories, I also provide suggestions on how to handle each type of error condition.

            In general, errors a program can encounter tend to be the result of one of three things:

            • Restrictions: Arguments to a routine that can never work, and always result in an error, define a restriction on the use of the routine. Ensuring that only correct arguments are passed to a routine is the type of thing that programming by contract is meant to address.
            • Inconsistencies: When values or resources are not what they are expected to be, or are missing, that creates an inconsistency between the expected state of the environment and the actual state. This may be the internal environment, such as a null pointer, or the external environment, such as a corrupt file. It doesn't encompass inconsistencies in the data model, which often needs to be temporarily inconsistent during an operation (e.g. adding a node to a linked list).
            • Failures When an operation simply does not work, and it's out of the program's control, this is a failure. For example, a pulled network cable.

            These types of errors overlap to an extent (say, a working network could be considered part of the expected state, making it an inconsistency error). In general, though, most errors can fall into one of these categories.

            Sometimes failures are not errors, and are just a way of detecting the current external state. For example, opening a file that doesn't exist may fail, but results in an error only when that file is actually needed.

            Error Handling Responsibilities

            Program code is responsible for the consistency of the internal program state. Generally certain code has primary (ideally, exclusive) responsibility for parts of the internal state. Inconsistency errors that occur within the code responsible for that state are bugs.

            Sometimes the state management responsibility is shared between different sections of code. This is a bad idea, because it makes assigning responsibility for an inconsistency error harder, but it does happen in practice.

            It's important to make a distinction between error detection and debugging. Often, data generated in the process of error handling is mixed together with diagnostic information. If possible, these types of information should be kept completely separate—at least conceptually, even if combined in a single data structure.

            Safe Zones

            Restrictions can be checked before calling a routine, or within a routine. It seems a waste of time to check arguments every time a routine is called when you already know those arguments are correct. One strategy is to separate parameter checking from parameter usage. This doesn't work reliably for library code, where anything can happen between the check and the use of the parameters, but within a base of code for a particular application or within a library, you can restrict the code to not change a value known to be safe.

            The code between a parameter check and the next change to a parameter variable is a safe zone, where parameters don't have to be re-checked. This is only valid for restriction errors, because inconsistency and failure errors can be caused by things outside the code's safe zone. Things like critical sections (in multithreaded environments), semaphores and file locks are meant to create a very limited kind of safe zone for inconsistency and failure errors.

            The code safe zones for parameters can overlap with others, and may not be well defined. One way to deal with this is to assign known safe values to variables which indicate this safety. Joel Spolsky wrote about one way to do this using variable naming conventions in Making Wrong Code Look Wrong. Safe values should be assigned to variables declared constant.

            Reporting Errors

            Code calling a routine needs to know three things to decide how to proceed: First, whether the data is returned, if any, or if the method invocation succeeded; second, whether an error occurred; and, third, whether the error is permanent or transitory. This defines the following possible error states returned from a routine:

            1. Successful
            2. Restriction error (always permanent)
            3. Permanent (bug) inconsistency
            4. Transitory (detected) inconsistency
            5. Failure (transitory for all we know)

            It's often a bad idea to mix an error code with a return value, such as designating a specific values—say, 0 or -1—to be invalid. Some languages, like Python, allow multiple values to be returned from a method as tuples. A tuple is basically an anonymous class, and can be implemented in a language like Java by defining a class for objects returned by a method, or in C by defining a struct which is passed as a parameter and is updated by the function. But in many cases, exceptions are a much better way to separate error information from return values.

            Exceptions transmit an object from the exception location to a handler in a scope surrounding it, or surrounding the point where the routine was called. The exception objects include information by the object type and class, and debugging information the data contained within that type. Exceptions by themselves don't indicate the error state, so that must be included as an attribute of the exception object, or the error state must be deduced from the debugging information (object type and data).

            Java introduced the controversial notion of checked exceptions, which must either be caught or declared to be thrown by a method in order to compile, while unchecked (or runtime) exceptions behave like exceptions in other languages. The main cause of the controversy is that there has been no good definition of why there should be a difference and, as a result, no consistent strategy in the implementation in various libraries, including standard parts of the different Java runtime libraries.

            In general, unchecked exceptions are meant for bugs, where an error indicates that the code is simply wrong and must be fixed (restriction and bug inconsistency errors). An example is a NullPointerException. Checked exceptions are for detected inconsistency and failure errors, where the program may have a strategy of handling the error. An example is an I/O error.

            Transactional Operations

            One strategy to handle errors is to make all operations transactional, so that if they fail, it's as if the operation was never tried. One way implement this is to define an "undo" operation for every change:

            Ideal transactional function

            In this example, the functions are also transactional, and thus don't need to be rolled back if they fail. This can be done with nested if/else blocks, or with nested try/catch blocks. If the "undo" operations themselves have errors, the result looks more like this:

            Realistic transactional function

            One way of dealing with this is to modify a copy of the program state, and if all operations succeed, only then commit the changes. The commit may fail, but this isolates the possible state changing errors to one point, and is similar how databases implement transactions. Another way to implement transactional operations is to make a copy of before any state is changed, and use that copy to restore the expected state, in case of an error.

            In summary, having a clear taxonomy of error conditions that code may encounter helps develop better strategies for dealing with, and possibly recovering from, those errors.

            posted on 2007-07-15 18:31 愛上龍卷風 閱讀(1137) 評論(0)  編輯 收藏 引用
            欧美综合天天夜夜久久| 伊人久久大香线蕉综合5g| 久久亚洲美女精品国产精品| 久久国产免费观看精品3| 久久精品国产只有精品2020| 久久亚洲欧洲国产综合| 亚洲国产婷婷香蕉久久久久久| 亚洲精品无码成人片久久| 国产精品9999久久久久| 久久本道久久综合伊人| 色欲av伊人久久大香线蕉影院| 久久精品国产99国产精偷| 综合久久精品色| 热99re久久国超精品首页| 久久久久国产一级毛片高清板| 少妇久久久久久被弄高潮| 国产精品日韩欧美久久综合| 日韩人妻无码精品久久免费一| 久久精品成人一区二区三区| 九九精品99久久久香蕉| 人妻中文久久久久| 国产精品成人久久久久三级午夜电影| 欧美日韩精品久久久久| 99久久精品国产综合一区| 色综合久久中文字幕无码| 久久国产精品免费一区| 久久97精品久久久久久久不卡| 精品国产99久久久久久麻豆 | 欧美伊人久久大香线蕉综合 | 久久青草国产手机看片福利盒子| 亚洲国产成人乱码精品女人久久久不卡 | 亚洲а∨天堂久久精品9966| 久久精品国产99国产电影网| 国产精品99精品久久免费| 久久天天躁狠狠躁夜夜96流白浆 | 久久久久人妻精品一区三寸蜜桃| 久久久国产精品亚洲一区| 97精品伊人久久久大香线蕉| 中文字幕热久久久久久久| 久久精品日日躁夜夜躁欧美| 亚洲级αV无码毛片久久精品|