Assert and application

[Rafael]

Hello List


I'm working in a logging library, and wondering:

How would you like to get a function input error? Assert, EXIT_FAILURE
or even default behavior on failure?

Like:

startup(int safe, int logto, int clear, const char* file)

assert((conf) && (file) && (safe>=0 && safe<=1) && (logto>=-1 &&
logto<=2) && (clear>=0 && clear<=1));

Hijacking my own thread, I like to know if you think is better to just
set a global variable with your function initialization data (since you
should not handle that data, anyway) or get the pointer back and pass as
argument each time you call the function.

Thanks
Rafael

 

[vippstar]

Hello List

I'm working in a logging library, and wondering:

How would you like to get a function input error? Assert, EXIT_FAILURE
or even default behavior on failure?

When the wrong arguments are passed in a function I don't care for its
behavior, but it's helpful when the function itself tells you
something went wrong. 'default' behavior usually hides the actual
problem.

 

[Rafael]

(e-mail address removed) escreveu:

When the wrong arguments are passed in a function I don't care for its
behavior, but it's helpful when the function itself tells you
something went wrong. 'default' behavior usually hides the actual
problem.

Hello Vippstar, List

Thanks for your reply.

The issue is: that system should be some how "bullet proof". It's a
aircraft device, really cant exit(o) on failure. That's why I was
wondering if asserts (witch with the correct preprocessor could be
disabled) couldn't be the answer to get a clear cause of problems.

EXIT_FAILURE will rely on 3 part error handling (and I usually don't
know who the 3 part is, so, doc's reader dependent solution).

Default behavior... well... I know that's not a good solution at all,
but I think, if I just don't like to depend on coder commitment to rtfm,
and asserts aren't the way to go, my last solution.

Of course, if the logging lib fails, there is no place to get error
messages (the general purpose of the library is to fill all possible
options - stdout is not one of that).

Regards
Rafael

 

[Rafael]

Hello Malcolm, List

Malcolm McLean escreveu:

By "function input error" we normally mean "error by the calling
programmer". assert() is designed to handle this eventuality. It will
stop the program in short order in debug mode, which is what you want.

Yes, thats exactly what I mean.

In release, you cna either ignore asserts and hope, or stop the program,
depending on what sort of program it is.

The nature is exactly the issue. The program should be as "non-stop" as
possible. Too, I would like to provide the logs anyway, if the user
option is not a option (yes, another issue - the environment can change).

Lets take this picture:

Aircraft is on the flight. Electrical failure take down calling
programmer storage option 1.

Here, asserts will just be ignored (application MUST be release),
logging will not happen, except IF caller have more then one storage
option set on initialization;

Return (EXIT_FAILURE) will be just plus one thing to the caller to take
care.

Default behavior - seek for working storage option?

That's the only thing I should really care. If logging is verbose or
just panic, the main problems will be logged anyway (disable panic is
not a option on the library).

Just figure - I can mix both assert and default behavior. That fix my
problems. And bring me others. I think that will be my solution.

Thanks

Regards
Rafael

 

[Richard Tobin]

I'm working in a logging library, and wondering:

How would you like to get a function input error? Assert, EXIT_FAILURE
or even default behavior on failure?

assert() is controlled by the value of the NDEBUG macro, and in
particular its value when the code calling assert() is compiled. So
it's determined when your library is compiled, not when the user's
program is compiled.

Since the user of the library may not have the inclination (of even
the ability) the recompile your library, it's not an ideal debugging
tool for them. assert() is more effective as a way of debugging
*your* code, rather than some future user's.

That leaves you with several possibilities including: abort()ing
unconditionally, abort() conditionally according to user flag, relying
on something like a segmentation fault to catch the error, or
returning an error status.

Consider things like: could a user reasonably take action to correct
the error if I return an error status? if I continue in the face of a
bogus value, is it like to corrupt data?

-- Richard