Equip the exit functions with a return value.

[powerlink-team-kalycito]

Exit functions in the POWERLINK modules does not return a value for handling. If the user tries to re run the POWERLINK application after an unsuccessful "POWERLINK exit" the user will be facing errors due to improper exit, so the previous error handling traces will support the user to debug and progress further.

Identified in Stack version: oPLK v2.5.2

[seissw]

In my opinion, an exit or cleanup routine shall never fail. It may log some debug messages, though, but it has to ensure that all (or at least as much as possible) resources are freed before shutting down. (Cf. with destructors in OOP that do not have any return type and shall also not throw any exceptions.)

Other opinions?

[banickn]

It would be interesting which functions you're specifically referring to.
For example:
oplk_destroy() which calls ctrlu_shutdownStack() returns an error and debug messages when shutting down the user modules.
On the other hand: A function like oplk_exit() does not do that.

Even though lots of crucial init functions do a memset with zeros, it might make sense to get the exit behaviour a bit more consistent.

[zelenkaj]

Hello!

In my view *_exit() functions shall all have no return value at all. The shutdown/cleanup shall continue and any kind of shutdown issue shall be traced for debug purpose only. The trace function call shall be done at the level where most information can be obtained from the return/error code. So, extending Norman's example and assuming an error in edrv during cleanup: I would prefer the debug trace in edrv_exit() than in ctrlu_shutdownStack() or oplk_destroy(), because in edrv_exit() I'am able to add extra information such as "disable link failed with error 0x1234", and that helps tracking down problems.

So handle and trace issues right away!!!

Best regards,
Joerg