To catch or not to catch

Should application catch "bad" signals s开发者_运维问答uch as SIGSEV, SIGBUS?

---

Those signals are produced in "should never happen" circumstances, when your program is in an undefined state. If you did catch them, continuing execution would be extremely problemeatic, as it would almost certainly cause more, possibly even more severe, errors. Also, if you don't catch them, the OS may be able to do things like produce useful diagnostics such as core dumps. So I would say "no", unless you don't want the core dump, and your error handling does something very simple such as write to a log and terminate.

---

Only if you have something more meaningful to do than the default action. You can't do very much more than aborting quite rapidly but sometimes trying to save the current work is adequate. But pay attention at not overwriting existing files -- users don't like the replacement of good files even if outdated with garbage.

---

No you should not. I know it's tempting. But there are only very very few reasons why you would ever want to catch fatal signals such as SIGSEV and SIGBUS.

One of the few exceptions might be to have some extra signalling/postmortem code which tells that your program has failed. Even this should only be done in controlled environments, not in code that ships to hundreds of thousands of users.

You have to be prepared that your postmortem code itself will crash though because SIGSEV and SIGBUS are signs of defective code or data.

---

There can be situation where you must catch signals like SIGSEGV and SIGBUS: one such example is: your pointer points to a mmaped region of memory and you are doing *ptr=x and for example this memory address belongs to a network file and your network is throwing some errors. at this point the only way to do error checking is catch the signal and retry or do something else.