Repository navigation
Completion of error handling #852
Description
Would you like to add more error handling for return values from functions like the following?
- printf ⇒ usage
- strdup ⇒ readup_str
Would you like to add more error handling for return values from functions like the following?
Activity
- Fix for #852: Completion of error handling.
wcawijngaards commentedon Feb 23, 2023
The strdup call is nicer with error handling. It is added in the commit above. The prints in the usage printout routine from unbound-control do not need such error handling, I would think.
Thanks for the heads up on the error oversight in the test program! That is nice to have a fix for.
elfring commentedon Feb 23, 2023
I suggest to avoid ignorance of return values a bit more.
Would you like to detect every error situation as early as possible?
wcawijngaards commentedon Feb 23, 2023
I think it is a good idea to avoid ignorance of return values. But for such print statements, in the usage output, I think that is not nicer to check them.
There are a number of
(void)casts that are used when return values are not inspected, already in the code. So that coverage can be extended. The value of this is debatable, it turns maybe into too many false positives and clutter. Or maybe it is useful as an annotation.elfring commentedon Feb 23, 2023
💭 I propose to take also the possibility better into account for data output failures.
wcawijngaards commentedon Feb 23, 2023
Yes, it is important to check for data output failures. For that, checking the return value of print function when NSD is printing to file, in other places, is important. But the usage error text data output is not significant.
The annotation, if useful for analysis, could prove useful. That could be a reason to add it.
Of course, we want the code to be as good as possible. I am not sure how this change would impact benefits from that programming paradigm.
elfring commentedon Feb 23, 2023
🤔 Can you become more aware that error detection belongs to known cross-cutting concerns?
wcawijngaards commentedon Feb 23, 2023
Yes, that is true, that error handling fits in that way. That is interesting to read. :-)
For the usage printout, I think the result of handling the errors would make for annotated non-handling of it. Handling it to then try to printout another error that error printout does not work is not an improvement in program functionality for the usage printout, I think.
elfring commentedon Feb 23, 2023
👀 Some development approaches are worth for another look, aren't they?
Merge remote-tracking branch 'nlnet/master'