On Oct 5, 2010, at 2:56 PM, Daniel Walter wrote:
I am writing the third-party library's and need these library's to handle signals. In particular I am looking to trap things like NULL pointer references and divide by zero errors, but SIGPIPE and other signals are important as well. We use crash dumps generated from these failures to improve our software quality. Additionally, our crashes are less damaging because they don't bring down larger applications.
You can't selectively trap those exceptions (since the code generating the exception message has no idea of the division of labour within the address space).
However, you can certainly arrange to have exceptions delivered to your handler so that you can perform your own filtering. Your mistake is in assuming that you want to handle signals, which are not the primary delivery mechanism.
I'm not certain that you can do this without disturbing other exception listeners in your task; you may need to piggyback or co-operate in some other fashion - a bit of googling will probably cover you there.
While I want to trap the problems that occur while executing my third party library code, I want my program to be generally well behaved and not screw around with the signals that occur while running the main program.
This is in general not easy to arrange; you will need to filter exceptions as they are delivered in order to decide who is/may be responsible for them.
Do note that if you're just doing this for your internal use, the system already catches exceptions and generates backtraces for apps that crash. If you want to extend this mechanism for your own apps, there are plenty of examples of building app crash catchers out there. Consider e.g.
http://cmcrashreporter.codingmammoth.com/HTH.