importance of catching signals

[Ceset]

hi guys

i was reading some articles and come across such a thing called signals.

i made many searches but now i m more confused.

what is the importance of catching a signal when writing a program?? and what should be the answer the program gives if it is important??

sorry if i m not asking a proper question. couse i dont understand it very well at the moment

[Bourgond Aries]

I believe signals are only used on POSIX systems, so maybe this is a UNIX/Linux programming question.

I believe there are standard signal catchers that print a message like: "Segmentation Fault" and then call and exit function to exit the program. You could write your own signal handlers tho.

I believe; to catch signals, you need to define a void function, include <signal.h>, and set the new signal handler using signal(SIGNAL_ID, function);

Catching a signal will not be so beneficial, it'll most likely be hard to recover from one and a signal (in my cases) do not point me to the part that for example segfaulted, exceptions can give me more information with ::at() functions in STL containers.

[Ceset]

ty it was very helpful

[kbw]

The equivalent on Windows is called Structured Exceptions.

Signals give you an opportunity to do something helpful/intelligent before an application dies.

For example, I am currently working on an API that notifies the system if a user process of the API crashes or is terminated by an unhandled C++ exception.

I worked on a Windows app that ran on a server farm that wrote run-time stuff the some other part of the system before it died.

[Ceset]

so it is not a must but a plus for the program

[S6k9GNh0]

Ceset, yeah. A lot of programs choose not to deal with signals at all.