Completion of error handling

[elfring]

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

• malloc ⇒ __do_discover_devices_1
• pthread_mutex_init ⇒ __coprthr_init_event

[browndeer]

Here it depends. In some cases return values are not checked for errors
simply because they were ignored during development, but should be
corrected to tighten up the code. In other cases, individual error codes
are not checked in favor of checks higher up, especially for code that
must be fast, so performance is favored over error specificity in very
unlikely scenarios, for example pthread_mutex_init, I do not consider this
likely to fail unless something is very wrong, in which case I will accept
a crash. This is a judgment call, and subject to debate, but everything
is a tradeoff. Finally, in some cases, for example, internal calls like
_do*() functions, there is deliberately minimal checking of parameters
since these should be checked at the layer above it, and the redundancy is
intended to be avoided. This does not address your question, but I would
say here also we prefer effective error checks, not a myriad of checks for
every small thing. Short answer, yes, but it depends.

-DAR

[elfring]

Would you like to detect every error situation as early as possible?

[browndeer]

Would you like to detect every error situation as early as possible?

Good question. It depends. Preference is earlier the better _unless_ late detection leads to same outcome (program crashes with error) _and_ a late detection is more efficient in critical code. As a corollary, I am perfectly happy with a seg fault to occur as opposed to providing the user with obscure information they cannot do anything with. So if you perform 10 steps, all of which can fail, but the 10th step is guaranteed to fail if any of the prior 9 failed, then I would check the 10th step late. In critical code. Its just a tradeoff. Hope that explains what might be an odd response of "maybe". However, in most cases, yes, detecting error as early as possible is best. I should mention I introduced clerrno and oclerrno to provide better error reporting, but I am certain I have not made full use of it. Any improvements to error reporting, I would tie to that system modeled after errno. I can say more about why if interested.

…

-DAR

[elfring]

How do you think about to improve static source code analysis also for your software?

Do you find information sources like the following useful?

• Article "A Reusable Aspect for Memory Allocation Checking"
• Document "Aspect-Oriented Software Development - An Introduction" by Johan Brichau and Theo D'Hondt
• Paper "On Typesafe Aspect Implementations in C++" by Daniel Lohmann and Olaf Spinczyk

[browndeer]

How do you think about to improve static source code
analysis also for your software?

Possibly. Can you recommend a tool that would be particularly good with
this type of software that we might take a look at?

Do you find information sources like the following useful?

• Article "A Reusable Aspect for Memory Allocation
  Checking"
• Document "Aspect-Oriented Software Development - An
  Introduction" by Johan Brichau and Theo D'Hondt
• Paper "On Typesafe Aspect Implementations in
  C++" by Daniel Lohmann and Olaf Spinczyk

To my understanding, the concept might be useful, but I would need to see
how it helps. We try to follow the FreeBSD design principles (adopted
from X11) so there will be resistance to a complicated solution when a
simpler one suffices. Also, and I am not quite sure I interpret this
correctly, but if the idea is anything like catch-throw semantics in C++,
this is not of interest and something I find to be quite bad in design.
The present error reporting system, while not fully built out perhaps, is
much preferred. I should say also, there is no interest in moving to a
C++ design at this layer, it will remain C. This is not an aversion to
C++, I use it for many other things, but not at this layer.

Thanks for the suggestions. I do appreciate them.

-DAR

[elfring]

I recommend to pick an improved analysis tool at all. 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?