• <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)  編輯 收藏 引用
            久久亚洲欧洲国产综合| 99久久超碰中文字幕伊人| 韩国三级中文字幕hd久久精品 | 精品国产乱码久久久久久呢 | 久久久噜噜噜久久中文福利| 久久超碰97人人做人人爱| 亚洲乱亚洲乱淫久久| 亚州日韩精品专区久久久| 三上悠亚久久精品| 久久精品中文字幕有码| 亚洲国产精品久久久天堂| 99久久无码一区人妻| 亚洲AV无码久久精品色欲| 韩国三级中文字幕hd久久精品| 亚洲va久久久噜噜噜久久| 久久久久久久久久久免费精品| 一本色道久久88—综合亚洲精品| 香蕉久久一区二区不卡无毒影院| 亚洲国产天堂久久久久久| 欧美综合天天夜夜久久| 日本人妻丰满熟妇久久久久久| 久久九九久精品国产| 国产精品久久久久久| 亚洲人成伊人成综合网久久久| 精品久久人人做人人爽综合| 久久精品夜夜夜夜夜久久| 久久人人爽人人爽人人片AV东京热| 99久久精品费精品国产| 久久久婷婷五月亚洲97号色| 久久精品国产亚洲av麻豆图片 | 久久亚洲中文字幕精品一区| 国产成人精品久久| 99久久精品免费看国产一区二区三区 | 国产精品成人久久久久久久| 国产精品久久久亚洲| 国产亚洲精品久久久久秋霞| 伊色综合久久之综合久久| 久久天天躁狠狠躁夜夜不卡 | 久久亚洲AV成人无码国产| 久久亚洲国产最新网站| 伊人色综合九久久天天蜜桃|