Re: unexpected exception handler
- From: George <George@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Jan 2008 22:46:28 -0800
Hi Igor,
I have two more points which are different from yours,
1.
I consider the outcome of hardware I/O as input to the state machine,
not part of the machine itself. This way, the machine is still
deterministic, the input just changes from run to run (which is
completely expected).
I think there does exist H/W fail. For example, some register (which has
something wrong physically) in H/W returns random output according to
definite input. Any comments?
2.
However, C++ exceptions still don't come out of nowhere. Your code has
generated them (in response to OS returning error code from its API, or
otherwise).
My code (application code which utilizes STL I/O steam) just rethrow of
throw another exception, it is the STL lib which throws the exception -- not
my code. :-)
For example, as you mentioned before, we could use basic_ios::exception() to
set the STL to throw exception when there are any errors. Any comments?
regards,
George
"Igor Tandetnik" wrote:
Ben Voigt [C++ MVP] <rbv@xxxxxxxxxxxxx> wrote:.
You sound as if exceptions just happen unpredictably, like
earthquakes or tornadoes. Computers are deterministic state
machines. Exceptions don't occur at random, they are thrown by some
piece of code in your application. You are basically saying that you
have no idea what your
That's not accurate. Computers have a lot of non-determinism. Some,
like timing of hardware I/O, the software should expect and process
without exceptions.
I consider the outcome of hardware I/O as input to the state machine,
not part of the machine itself. This way, the machine is still
deterministic, the input just changes from run to run (which is
completely expected).
Others, like network or disk checksum failures,
the software should expect and may generate exceptions for internal
flow control.
However, C++ exceptions still don't come out of nowhere. Your code has
generated them (in response to OS returning error code from its API, or
otherwise).
But yet others, like memory bit errors, could occur
asynchronously and are reported by a exception generated by hardware,
randomly and from the level of abstraction of application software,
perfectly so.
Personally, I feel that when an error like this occurs, the process is
better off just dying then and there. How can one reasonably recover
when bits are flipped randomly in one's data structures?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
- Follow-Ups:
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- References:
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- From: George
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- From: George
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- From: Ben Voigt [C++ MVP]
- Re: unexpected exception handler
- From: Igor Tandetnik
- Re: unexpected exception handler
- Prev by Date: Re: unexpected exception handler
- Next by Date: Re: unexpected exception handler
- Previous by thread: Re: unexpected exception handler
- Next by thread: Re: unexpected exception handler
- Index(es):
Relevant Pages
|