signal handling and (structured) exception handling

signal handling and (structured) exception handling

Post by Pete » Sat, 10 Oct 2009 09:18:39


I'm a little bit at loss, why the new C++ standard (C++0x) does not
include something like Windows structured exception handling.
I certainly prefer a C++ Exception to 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 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.

Even in case of a null pointer access I would prefer to keep the
application running to be able to terminate it correctly. 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.

Another example is a floating point exception.
With exception handling I could avoid having to secure the code
against invalid inputs,
which also slows it down.
 
 
 

signal handling and (structured) exception handling

Post by Victor Baz » Sat, 10 Oct 2009 10:05:21


Why should it be included in the Standard (new or old) when any
implementation is free to provide its own way of dealing with those?


Signals aren't really normative, are they?


Access to null pointer has undefined behaviour. The implementation is
free to define it. Some do. Some don't. There is no need to introduce
limitations by specifying what should happen.

> In this case

Whatever. If you're using a sophisticated operating system that allows
you to handle such a situation, be happy. You seem unhappy for some
reason. Do you want your Windows application with all the SEH stuff be
runable on MS-DOS? And you want the language to provide the means? I
do not see this as reasonable.


Slows it down? By how much? I've worked in systems that were set up to
handle FP exceptions and invalid pointer access... If you want it done
right, every damn function has to be littered with try/catch for those.
It is much, MUCH, easier to make sure you never try to calculate a
logarithm of a negative value or you never hang onto a dangling pointer.
A test for greater than 0 is so much quicker than setting everything
up for stack unwinding...

But you don't have to listen to me. If you see how Microsoft Structured
Exceptions can be brought into the language and implemented everywhere
the C++ compilers can exist, do write it up. I am sure folks in
comp.std.c++ will read your proposal with the same attention they give
every proposal.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

 
 
 

signal handling and (structured) exception handling

Post by Ross A. Fi » Sat, 10 Oct 2009 11:01:02

n Oct 8, 6:05m, Victor Bazarov < XXXX@XXXXX.COM > wrote:

Signals are normative. There is lots of informative left out of the
normative (standard).

> logarithm of a negative value or you never hang onto a dangling pointer.> > A test for greater than 0 is so much quicker than setting everythin>
> up for stack unwinding..>
> But you don't have to listen to me. f you see how Microsoft Structure>
> Exceptions can be brought into the language and implemented everywher>
> the C++ compilers can exist, do write it up. am sure folks i>
> comp.std.c++ will read your proposal with the same attention they giv>
> every proposal>
> >
> ->
> Please remove capital 'A's when replying by e-mai>
> I do not respond to top-posted replies, please don't ask

It seems reasonable as a pattern to encapsulate generic exception
handling in the C++ towards that it is instrumentable generally.

Here are some of my ideas from the other day about cwd: current
working directory. When considering how to handle the exceptions
generally, catch the signals and throw them back to the functions
maybe having each function register itself as the signal handler, in
the generic exception handling logic.

Also I am thinking some about "generic return types" and also
generifed return types in terms of considering what C++ can do for me.

To truncate the file specifications might be great, with the automatic
matching of the free input component.

static cwd here

put static functions on cwd, then use here for the file functions,
file_system_point

class cwd
{
std::string directory; // this is the current working directory
directory
}



use the inline functions, anonymous functions, to, defer
initialization of the carry-over variable

if there's no initial match, it's set to zero

here, the point is to collect several modes of the strings, basically
having the modes saved in the static variables

so, the path comes in, is it a delta off of the working directory, or
absolute / rooted?

basically for the path root, there is either the working directory as
the root or the path contains its own root (which might include
volume, host, etcetera, which would have static process events on
events with those).

So, I want to get the path, and compare it to the working directory.
If it's relative the working directory, then truncate it's initial
matching segments, the parameter, for later calls using the same
initial segment.

Then set up mode arrays, with this path construction and validation
generally throughout with public APIs.

So, the mode strings should be any number of matching initial segments
and patterns.

Then, among those are to be the collapse and the matching of the
segments / strings.

Make the path components, similar to the path segments, with getting
out the names.

So, to match the working directory, it's towards where the actual
parameters can be reduced, until, they have to be assembled already to
access the device or so, here relative to particular points they have
more direct addressing which carries down to all the functions
underneath, where for example there is a static main process working
directory object that the static function members initialize to.

Then, it is more about instrumenting the function with automatically
recognizing its input types, memoizing its inputs, than it is about
particularly the working directory as a process
 
 
 

signal handling and (structured) exception handling

Post by Pete » Tue, 13 Oct 2009 09:14:51


> 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.

>> 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.

>>>> 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? nly 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.

>>>> 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. hatever >> happens in such cases is implementation defined.



Yes again -- you could start removing features of C++ to enable it to
cover more platforms.

>>>> 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

>> >>>> 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.



I think you should not be posting answers to this forum.
Also -- being able to understand written english is also helpful.
 
 
 

signal handling and (structured) exception handling

Post by Pete » Tue, 13 Oct 2009 09:30:22

n Oct 8, 6:05m, Victor Bazarov < XXXX@XXXXX.COM > wrote:


You seem not able to understand the need for a standard.





Read my post. I gave multiple examples fro such need.




I was asking why this obviously useful feature (structured exception
handling)
is not part of the standard.
Why are you bringing up MSDOS?

>> >>>> Another example is a floating pointexception. >>>> Withexceptionhandling I could avoid having to secure the code >>>> against invalid inputs, >>>> which also slows it down. >> >> Slows it down? y how much? 've worked in systems that were set up to >> handle FP exceptions and invalid pointer access... f you want it done >> right, every damn function has to be littered with try/catch for those.


The advantage of C++ exception handling is that you do not have to
check for success everywhere.
Try-catch-blocks should be rare in good code.
If you are not aware of this, you should not be aswering questions
here.

>> It is much, MUCH, easier to make sure you never try to calculate a> > logarithm of a negative value or you never hang onto a dangling pointer.> > A test for greater than 0 is so much quicker than setting everythin>
> up for stack unwinding...


I'm not talking about a single fallible call to log() or sqrt() or asin
().
I'm talking about some 1000 lines of math code, with multiple inputs
and multiple outputs.
Or maybe even higher up in the call-stack -- our simulator only needs
to know, that there was a single instance of some model
(and there are a couple of thousands with every model having around
1000 lines of math code),
which was unable to deal with the current voltage vector. >
> But you don't have to listen to me. f you see how Microsoft Structure>
> Exceptions can be brought into the language and implemented everywher>
> the C++ compilers can exist, do write it up. am sure folks i>
> comp.std.c++ will read your proposal with the same attention they giv>
> every proposal.


I just wanted to express my curiousity about the fact, that they
(being smart people) did not get this idea by themselfs already.
 
 
 

signal handling and (structured) exception handling

Post by Pete » Wed, 14 Oct 2009 02:57:34


The first CPU I came in contact with (Z80) did not have any feature to
call via a pointer stored somewhere -- it could call only to a fixed
address. Maybe you could emulate it via manipulating the stack and
executing return.

The standard could simply claim, that on machines which support memory
protection, a C++ exception should be thrown instead of a signal. This
would cover all of the platforms I have to deal with (various UNIXs
and Windows).
 
 
 

signal handling and (structured) exception handling

Post by Noah Rober » Wed, 14 Oct 2009 05:51:18

In article <62f74dc5-490a-416d-8e3b-658690942e41
@b25g2000prb.googlegroups.com>, XXXX@XXXXX.COM says...

Because signals and exceptions are for totally different things.


Use a smart pointer and throw an exception when ->* is called on 0.


Some may disagree but I'd recommend against this line of reasoning.
Exception handling is not a replacement for input validation.
 
 
 

signal handling and (structured) exception handling

Post by REH » Wed, 14 Oct 2009 06:36:10


What are you talking about? I've programmed Z80s for years. You can
jump to an address contained in the HL register pair: JMP (HL). You
can jump indirectly to an address stored in memory JMP (nn). Call has
the same ability.

REH
 
 
 

signal handling and (structured) exception handling

Post by REH » Wed, 14 Oct 2009 06:54:34


I looked up the opcodes verify my statements (it been a while). I
misremembered about JMP (nn) and call (that weirdly was how they
always listed the direct jumps even though parentheses where used for
indirection), but you can do an indirect jump via the HL register
pair. You can also do it using IX and IY indexing registers. No need
to manipulate the stack or make self-modifying code.

REH
 
 
 

signal handling and (structured) exception handling

Post by Pete Becke » Wed, 14 Oct 2009 22:42:08


Well, yes, but not in this context. There are significant restrictions
on what a portable program can do with signals, and portable signal
handling does not involve null pointer checks or any of the other
diagnostic things that are the subject of this thread.


--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
 
 
 

signal handling and (structured) exception handling

Post by Pete Becke » Wed, 14 Oct 2009 22:44:22


Floating-point math has NaNs and Infinities for exactly this reason:
just run the code flat out, and check for errors at the end.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
 
 
 

signal handling and (structured) exception handling

Post by Pete » Thu, 15 Oct 2009 04:19:44


Yes. E.g. "signals" is spelled fully differently than "exceptions".
What is your point?




This would involve an if-statement which results in additional machine
instructions.
The CPU is anyway checking for invalid memory access.




To know exactly which input values are going to result in a NAN or INF
value
is not possible for my code.
 
 
 

signal handling and (structured) exception handling

Post by Pete » Thu, 15 Oct 2009 04:31:17


> Sparc.

SOLARIS also has signals for SIGSEGV and floating point exceptions.

I used to convert structured exceptions on Windows into C++ exceptions
by setting the matching handler and throw from this handler a C++
exception matching the structured exception code -- to be able to
catch different types of exceptions depending on what had happend.

Both, the signal handlers and structured exception handling are
asynchron.
I think it is just a matter of the compiler -- to create code, which
is able to deal with exceptions thrown from a signal handler --
compiler switch /EHa with Microsofts Visual C++.

>> And more generally, the fact that C++ doesn't throw anexceptionin such cases is a major >> reason why people continue to >> use it---if there is an error in your code, anexceptionis the >> last thing you want. A C++exception, anyway, with destructors> > being called.)


I'm not following.
You are saying, that the reason people use C++ exception handling is
that it does not cover SIGSEGV?
I've never heared anybody complain about the existence of structured
exception handling on Windows.

Please explain why you could not do whatever you are doing in a signal
handler
in the matching exception handler (which is also a function which can
be installed like a signal handler).
 
 
 

signal handling and (structured) exception handling

Post by Victor Baz » Thu, 15 Oct 2009 05:10:49


It's not "not possible". It *probably* requires more effort than you're
willing to expend. Hardware FP exceptions are produced by some
calculations that usually can be identified and singled out for input
verification. For example, when calculating inverse matrix using the
determinant method, you only need to check the value of the determinant
once to avoid dividing by 0. You could also avoid overflow or underflow
by predicting the result of dividing by a large value or by a small
value. When you're about to calculate a square root, check the value
for negativity (and don't do it if it's negative). And so on. What you
seem to advocate is the use of exceptions (which can be quite expensive)
instead of picking apart your FP expressions to find the subexpressions
that can cause problems and then inserting simple, efficient (trust me,
they usually are) and more explicit checks. Those checks would allow
you to identify the problem to your user with much better detail than
the exceptions would.

Programming languages were created by lazy programmers. Programmers
should be lazy to be more productive (however paradoxical it sounds).
So, to paraphrase Einstein, be as lazy as possible, but not lazier.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
 
 
 

signal handling and (structured) exception handling

Post by Ian Collin » Thu, 15 Oct 2009 12:54:30


I don't think you'll find any *nix compiler/runtime that supports
throwing exceptions from a signal handler.

--
Ian Collins