## How users can abuse signals (and why some think it is good)

Now that you know how to create signals to which the users can connect easily and at any point in the signal emission process thanks to `g_signal_connect`, `g_signal_connect_after` and G_SIGNAL_RUN_LAST, it is time to look into how your users can and will screw you. This is also interesting to know how you too, can screw other people. This will make you feel good and eleet.

The users can:

- stop the emission of the signal at anytime

- override the default handler of the signal if it is stored as a function pointer in the class structure (which is the prefered way to create a default signal handler, as discussed in the previous section).

In both cases, the original programmer should be as careful as possible to write code which is resistant to the fact that the default handler of the signal might not able to run. This is obviously not the case in the example used in the previous sections since the write to the file depends on whether or not the default handler runs (however, this might be your goal: to allow the user to prevent the file write if he wishes to).

If all you want to do is to stop the signal emission from one of the callbacks you connected yourself, you can call `g_signal_stop_by_name`. Its use is very simple which is why I won't detail it further.

If the signal's default handler is just a class function pointer, it is also possible to override it yourself from the class_init function of a type which derives from the parent. That way, when the signal is emitted, the parent class will use the function provided by the child as a signal default handler. Of course, it is also possible (and recommended) to chain up from the child to the parent's default signal handler to ensure the integrity of the parent object.

Overriding a class method and chaining up was demonstrated in the section called “Object methods” which is why I won't bother to show exactly how to do it here again.