Re: signal handling and (structured) exception handling
On Oct 12, 1:14 am, Peter <excessph...@gmail.com> wrote:
On Oct 9, 12:49 am, James Kanze <james.ka...@gmail.com> wrote:
Two reasons, really. The first is a killer: it can't be
implemented on a lot of platforms (e.g. those without memory
management or protection).
So you are suggesting that we remove the C++ feature, which
allows calling via a virtual method table so to we are able to
run C++ programs on CPUs from 1960.
I don't know of any machine which can't support virtual
functions. Even today, however, machines which can raise an
asynchronous exception are rare.
The second is simply that it is a bad idea.
If you think like that, you should read up again about the
differences of signal handling and exception handling.
If you don't think like that, you should read up about how to
write robust software. The difference is not between signal
handling and exceptions; the difference is between immediately
aborting and doing a stack walkback.
I certainly prefer a C++Exceptionto a signal, as the
signal only gives you the choice to terminate the process
or mess around with something as ugly as setjmp/longjmp.
And when do you get a structuredexception? Only when there
is a serious program error, such that you can no longer be
sure of the environment, and the only reasonable thing (for
most applications) is to abort, as quickly as possible.
I gave 3 examples where an exception like on windows is
helpful or even needed. Read my post again.
You gave a few examples of exceptional cases. We certainly
don't want to start requiring something that is detrimental in
most cases, just to support some rare and special case.
And such signals/exceptions can sometimes not be avoided,
e.g. in case of the system runs out of disk space while
writing into memory created by memory mapped io from a
sparse file.
Which is definitely a special case; the C++ language itself
doesn't support memory mapped files or sparse files.
Whatever happens in such cases is implementation defined.
Yes again -- you could start removing features of C++ to
enable it to cover more platforms.
There's no feature here to remove. C++ doesn't support memory
mapped files or sparse files.
Even in case of a null pointer access I would prefer to
keep the application running to be able to terminate it
correctly.
So check for null, and do whatever you want.
You definitely did not get the main advantages of exception
handling (and you're posting answers in this forum??????):
1) no need to check for success anymore
2) being able to catch errors 0 or more levels down the stack
3) being able to abort constructors
I understand when and where to use exceptions. I also
understand that when it comes to error reporting, one size
doesn't fit all. If you don't check for null, then passing a
null pointer is a programming error. In most applications, that
means that you need to abort as quickly as possible. Without
running the risk of executing destructors and the like, which
might even make the situation worse.
In this case probably there is no need to try to execute the
last verb again, because it will run into the same null
pointer access -- but at least the destructors should work and
the application can be terminated correctly.
The problem is that when you've got an access violation
(accessing memory which doesn't belong to the process), it's
usually due to some previous memory overwrite, and you can't
(safely) execute destructors.
You did not read my post. I gave multiple useful examples.
And you are intentionally missing the point: we don't want to
require behavior that is detrimental most of the time, just to
support some rare and unusual case.
I think you should not be posting answers to this forum.
Really? Just because I don't want to make the language unusable
for most serious applications, just to support some special
case.
Also -- being able to understand written english is also
helpful.
If that were a requirement, you couldn't have posted the above,
since you manifestly didn't understand a word I wrote.
--
James Kanze