Completion of error handling

[elfring]

Would you like to add more error handling for return values from functions like the following?

• clock ⇒ readfile
• malloc ⇒ preprocess

[arunsrinivasan]

@elfring would be great for malloc to begin with.

[elfring]

I suggest to avoid ignorance of return values a bit more.

Are you interested to apply aspect-oriented software development?
How do you think about to encapsulate error detection and corresponding exception handling as a reusable aspect in your software?

[mattdowle]

Thanks for the suggestion @elfring. Aspect compiler sounds good but I'm not sure this warrants the time to integrate a different compiler into our CI. I did a grep -A 2 malloc *.c. We have 55 calls and admittedly it was difficult to check them all. I'm thinking we should follow a standard that the immediate line after the malloc should handle a fail. We have quite a few comments on the line afterwards, and sometimes several malloc checked together in one branch, so I can think about a simple way to handle this and then add a grep style check in CRAN_Release.cmd. But there will be other things Aspect might spot for us.
We also have Codacy running in CI. It has caught some problems but I'm not sure it catches this. I tried to search to find out if Codacy covers this, but I couldn't confirm it within 5 mins.
There's no harm at all for us to try Aspect, with a good chance of it finding problems for us. But I don't know how to integrate it into our CI and I fear it could take more time than it warrants.

[elfring]

Would you eventually prefer to work with the semantic patch language together (besides trying a tool like “AspectC++” out)?

[mattdowle]

@elfring It looks very interesting. Yes: maybe. The only barrier is the effort needed to try it and get to a stage where it shows some benefit. It has not been the case that Codacy has found much, for example.