Setting error codes other than 1?

[grantfirl]

It was suggested by @MicroTed in ufs-community/ccpp-physics#127 that it would be useful to start adding error codes in the caps that actually mean something other than "error present". The example given in the linked issue is to write errflg = 789 (just some integer other than 1) in the cap Fortran when a group requested by the host is not found in the suite. The host can more easily check an integer than parsing the string errmsg in order to handle the error appropriately. For the case given, if the radiation group is not present, set a logical flag in the host to avoid continuing to try to call radiation.

Rather than going ahead and just changing this one errflg in ccpp_prebuild and ccpp_capgen to handle one specific case, I'm wondering where we stand with respect to creating a better error reporting/handling system in the CCPP framework? If this isn't near the top of the priority list, could we at least start implementing (and documenting) error codes besides [0,1] that can be set by autogenerated code?

@dustinswales @mkavulich @peverwhee @nusbaume

[mkavulich]

This should probably be discussed in the larger context of better error handling in capgen, maybe related to #350?

[gold2718]

A few thoughts:

1. I am a fan of this idea. Having a file with pre-defined error codes sounds great and anyone can suggest a new one.
2. I'm pretty sure this same file can easily be used in any new error-handling system we decide to implement so no effort is wasted.
3. The same file, published as a table in the documentation can be used by parameterization writers.

[nusbaume]

I also agree that having "real" error codes would be quite valuable. My only additional comment would be that when the error is due to a process that already provides an integer or error message (e.g. iostat or iomsg when opening/reading a file; stat or errmsg when trying to allocate a variable), that the provided number or string should be passed out as well (either in the CCPP error code or error message), as sometimes that information can be helpful as well.

I should note that I don't think that is something that would be explicitly handled by the framework itself, but might be good practice to implement in CCPP-ized physics schemes once we allow for different kinds of error codes.