#786 Completion of error handling

[Markus Elfring]

I mentioned this issue in a short discussion during the exhibition "OpenRheinRuhr" on the previous weekend.

A few checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "printf" like in the function "handler_print" and from "signal" in the function "main"?
https://github.com/geany/geany/blob/d06e9f4575728093b3355de31ac8efb89e1a38b1/src/log.c#L72
https://github.com/geany/geany/blob/8f280ed884721a0a1c75462e428b9bcffb3ac527/src/main.c#L979

How do you think about to apply aspect-oriented software development for this use case?
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All
http://aspectc.org/

[Markus Elfring]

Would you like to look at more update candidates like the following that can be easily found with a tool like Coccinelle?
http://coccinelle.lip6.fr/

- build_read_project ⇒ build_read_commands
https://github.com/geany/geany/blob/f67ed6b63670d88dead6b00b7aec340e9d61a7ed/src/build.c#L2211

- utils_get_config_files ⇒ utils_mkdir
https://github.com/geany/geany/blob/13597df9dffdcbd3091aac224d20b1924c563bde/src/utils.c#L1991

How do you think about to annotate any interfaces with a function attribute like "warn_unused_result"?
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

[Lex Trotman]

The cases in log.c, main.c and build.c are all situations where testing the return values is of no use as there will be no alternative action if the calls fail, and it does not seem to be any benefit to add visual clutter of marking the result unused just to stop complaints from a tool not normally used by the project.

The utils_mkdir call doesn't make sense, more investigation needed.