计算机科学论坛--如何理解异常[转贴]

1. Penny Liang
12月29日下午9时58分显示选项

first, is exception object?,where it come from?

as far as i know,exception come from tow source.
1)someting unexpected error from outside of software itself
2)someting unexpected error inside the software,however,most of them is not
expection,and can't be fixed as bug later.

expection is somehow kind of a signal just show something,then it don't like
a object,its lifetime hard to tell both in routing itself or the caller.

--
Thanks & Regards,
Penny Liang
Email:jackli...@vip.sina.com;pennyliang...@software.nju.edu.cn

2. Penny Liang
12月29日下午10时01分显示选项

sorry

2)someting unexpected error inside the software,however,most of them is not
expection,and can be fixed like a bug later.[correct]

--
Thanks & Regards,
Penny Liang
Email:jackli...@vip.sina.com;pennyliang...@software.nju.edu.cn

"Penny Liang" <pennyliang...@software.nju.edu.cn> Ð´ÈëÓÊ¼þ
news:dp0q2e$49a$1@news.yaako.com...

- 隐藏被引用文字 -
- 显示引用的文字 -

> first, is exception object?,where it come from?

> as far as i know,exception come from tow source.
> 1)someting unexpected error from outside of software itself
> 2)someting unexpected error inside the software,however,most of them is
not
> expection,and can't be fixed as bug later.

> expection is somehow kind of a signal just show something,then it don't
like
> a object,its lifetime hard to tell both in routing itself or the caller.

> --
> Thanks & Regards,
> Penny Liang
> Email:jackli...@vip.sina.com;pennyliang...@software.nju.edu.cn

3. Penny Liang
12月29日下午10时03分显示选项

first, is exception object?,where it come from?

as far as i know,exception come from tow source.
1)someting unexpected error from outside of software itself,most of them are
exception which can't be predicted.
2)someting unexpected error inside the software,however,most of them are not
expection,and can be fixed as bug later.

expection is somehow kind of a signal just show something,then it don't like
a object,its lifetime hard to tell both in routing itself or the caller.

--
Thanks & Regards,
Penny Liang
Email:jackli...@vip.sina.com;pennyliang...@software.nju.edu.cn

4. Michael Redlich
12月30日上午7时15分显示选项

Hi, Penny:

Penny Liang wrote:
> first, is exception object?,where it come from?

If I read your question correctly, you would like to understand the
concept of an exception regardless of the programming language.

The exception handling mechanism that is implemented in object-oriented
programming languages such as C++ and Java was developed to eliminate
the problem of checking an overabundance of special return values,
e.g., 0 on success, -1 on error, that can obscure your programming
logic.

Exceptions are "raised" within an application to signal that something
truly exceptional happened during run-time. Raising an exception
involves "throwing" it to an exception handler. The handler will
either exit or resume gracefully without having causing a crash of some
kind.

Here's an example of how an exception handler can gracefully resume
application run-time.  Say you are iterating through a record set that
you acquired from a database.  The data in the result set may have NULL
values, but encountering a NULL value may cause a crash during
run-time.  You can setup the exception handler to ignore the NULL value
and just call the next value from the record set.

C++ and Java have excellent exception handling mechanisms built-in to
the language.

I hope this helps...

Mike.

5. Penny Liang
12月30日上午9时28分显示选项

--
Thanks & Regards,
Penny Liang
Email:jackli...@vip.sina.com;pennyliang...@software.nju.edu.cn

"Michael Redlich" <m...@redlich.net> ????
news:1135898150.543860.80020@g43g2000cwa.googlegroups.com...

- 隐藏被引用文字 -
- 显示引用的文字 -

> Hi, Penny:

> Penny Liang wrote:
> > first, is exception object?,where it come from?

> If I read your question correctly, you would like to understand the
> concept of an exception regardless of the programming language.

> The exception handling mechanism that is implemented in object-oriented
> programming languages such as C++ and Java was developed to eliminate
> the problem of checking an overabundance of special return values,
> e.g., 0 on success, -1 on error, that can obscure your programming
> logic.

> Exceptions are "raised" within an application to signal that something
> truly exceptional happened during run-time. Raising an exception
> involves "throwing" it to an exception handler. The handler will
> either exit or resume gracefully without having causing a crash of some
> kind.

Raising an exception or"throw" is regarded as a kind of goto-clause,which
find errors and rescue them centralized at a place which expcetion handler
control.
I dont think a routine should have the ability to raise expcetion, because
we could predicit it ,expection at some extend means something unexpected.

> Here's an example of how an exception handler can gracefully resume
> application run-time.  Say you are iterating through a record set that
> you acquired from a database.  The data in the result set may have NULL
> values, but encountering a NULL value may cause a crash during
> run-time.  You can setup the exception handler to ignore the NULL value
> and just call the next value from the record set.

null reference is an unexpected event sometimes,but i personly think it more
like the responsibility of caller than that of routine itself,as Design by
Contract viewpoint.

- 隐藏被引用文字 -
- 显示引用的文字 -

> C++ and Java have excellent exception handling mechanisms built-in to
> the language.

> I hope this helps...

> Mike.

6. Michael Redlich
12月30日下午10时35分显示选项

Hi Penny:

Penny Liang wrote:
> Raising an exception or"throw" is regarded as a kind of goto-clause,which
> find errors and rescue them centralized at a place which expcetion handler
> control.
> I dont think a routine should have the ability to raise expcetion, because
> we could predicit it ,expection at some extend means something unexpected.

In understand what your are saying, but I disagree. Even though you
can predict the possibility of an exception (such as not being able to
open a file), you should still account for that possibility especially
if having that file open is critical to the application. You want to
write robust, quality software, right?

The exception handling mechanism in C++ and Java also has a
stack-unwinding procedure to handle memory allocation from the point of
the "throw" to the catch clause. For example:

int fred()
    {
    //...
    try
        {
        //...
        george();
        harry();
        }
    catch()
        {
        }
    return 0;
    }

void george()
    {
    //...
    }

boolean harry()
    {
    //...
    if(...) // some crazy condition
        throw("could not open file");
    return true;
    }

Function fred(), containing a try block and catch clause, calls
functions george() and harry().  If an exception is thrown in harry(),
the exception handling routines unwinds the stack by reversing the
order of how the functions were called to look for an appropriate catch
clause.  That is, it will go to function george(), which has no catch
clause, then go to function fred() which does have a catch clause.  In
that process, any live objects are destroyed which means that
destructors are invoked in C++ and objects are marked for garbage
collection in Java.

I hope this helps...

Mike.

7. Dmitry A. Kazakov
12月29日下午11时32分显示选项

On Thu, 29 Dec 2005 21:58:46 +0800, Penny Liang wrote:
> first, is exception object?,where it come from?

Exception is not an object, but it can carry an object with.

Exception is not an error in the sense of an illegal state. Otherwise it
could not be handled. The states traversed by exception propagation are all
legal. From this point of view an exception is like an non-local return.

> expection is somehow kind of a signal just show something,then it don't like
> a object,its lifetime hard to tell both in routing itself or the caller.

This is a difficulty that one particular model faces: if you allow objects
of any type to be attached to exceptions, then you have the problem that
the lifetime of exception might exceed the object's scope, the scope of its
type etc. Disliked Java's contract model of exceptions somewhat eases the
problem, because it defines exception scopes and binds them to the scopes
of subroutines. Another approach is upward closures, which is seems to be
extremely heavy-weighted. Third approach is predefined frozen type of
exception objects with clear disadvantages.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

8. H. S. Lahman
12月31日上午2时37分显示选项

Responding to Liang...

> first, is exception object?,where it come from?

Form the Dictionary of Computing: "An event occurring during execution
of a program that makes continuation impossible or undesirable." The
key notion here is that the software has reached an unstable state where
the expected results are no longer possible.

Typically languages and OSes that formally support exceptions provide a
"sideways" context switch where the current thread of control flow is
aborted and processing continues elsewhere in the program. The purpose
of such support is to provide, at a minimum, a "graceful" abort of the
program (e.g., with diagnostics) and, ideally, recovery from the
unstable state (i.e., returning the software to a stable state) so that
the program can continue to execute in at least some useful fashion.

Sometimes the built-in exception handling facilities will collect
information about the context of the instability for use by the
exception handling code.  That information can be encapsulated in an
object.  Similarly, the exception handling software may be encapsulated
in an object.  But the exception itself is just a condition of
execution, not an object.

> expection is somehow kind of a signal just show something,then it don't like
> a object,its lifetime hard to tell both in routing itself or the caller.

Exceptions are often called 'signals' because originally the source of
exceptions was a hardware interrupt from the ALU (e.g., zero divide).
That is, the hardware interrupt signaled the existence of the exception
condition to the OS and, possibly, the application. (Modern use of DbC
correctness assertions also allows exceptions to be signaled from the
software itself.)

Note that an exception is technically not a software error; it is simply
the condition of instability. In most cases that instability is direct
a result of some software error, but it could be due simply to the
original notion of hardware failure (e.g., the network is down). That,
however, segues to an important issue related to signaling exceptions.

Generally one should only use exception handling to deal with truly
unexpected conditions. Whenever a potential condition is explicitly
addressed in requirements (e.g., a policy for an invalid login is
specified) or implicitly in the problem space (e.g., human users make
typos and network nodes cannot be relied upon to always be "up"), then
one should detect that condition and address it _within the normal flow
of control of the program_. IOW, such conditions are a reasonable
expectation and there should be an explicit IF-and-branch in the code
rather than signaling an exception for a "sideways" exit from the
current code to processing by an handler elsewhere.

[BTW, there are very good practical reasons for this.  Bullet-proof
exception handling support is very difficult to implement properly
because one cannot predict the nature of the instability (e.g., the call
stack frame may be trashed or there may be no more resource memory to
put up an informative dialog, inviting an infinite error loop).  As a
result, good exception handlers tend to have substantial overhead, so
that is a poor choice for routine context switching.  (OTOH, simplistic
exception handling, as in C++, has less overhead but is not very safe at
all so it tends not to work when one needs it most.)]

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	78.125ms