Library calls exit - possible solution about admesh HOT 7 CLOSED

Yeah, I in a couple cases I suppressed the exit(1) calls with plain returns (when applicable). Most exceptions are related to IO or defensive programming checks. I think your idea is fine.

from admesh.

Hi Miro,

I am not an active admesh user/developer. If you do not break admesh
itself - I will accept most of changes.

I have actually uploaded already updated admesh version into Debian [1]. It
has
already admesh, libadmesh1, libadmesh-dev and dbg-version. Would be
good to tag a newer version on GitHub to get it uploaded before the next
Debian freeze (deadline is 5th of November, but I would prefer to have one
month
to fix possible bugs).

[1] https://packages.qa.debian.org/a/admesh.html

Cheers

Anton

2014-07-04 23:23 GMT+02:00 Miro Hrončok [email protected]:

As admesh was never intended to be a library, it calls exit() on error.
That is not very developer friendly, as if someone uses admesh as a
library, he/she cannot catch the error and display it to the user properly.

I was thinking how to solve this problem without breaking the API by
changing all the void functions to int returning a susses/failure
information.

My idea is to add int error to stl_file structure. When a function call
fails, it would not exit, but instead just raises the error flag by setting
stl->error to 1.

When the error flag is raised, no other function would do anything.
Developer might want to clean the flag, that would be possible by some
function like stl_clean_error_flag() (or rewriting the error value back
to 0 manually). For safe usage, after all function calls, the developer
should check the error flag and do whatever he/she wants about it: display
an error message, exit, or do something completely different.

For convenience I plan a function stl_exit_on_error() that would clean
the memory and exit.

I do not plan to store textual information about what happened, because
there are only few places when an exit is happening now and it is pretty
clear form the context.

I would like to hear some thoughts about this from others, especially from
@alexrj https://github.com/alexrj -> would this be acceptable for
slic3r? I think you have deleted some exit statements already and the error
detection might be nice... ?

cc @gladk https://github.com/gladk @kliment https://github.com/kliment
@iXce https://github.com/iXce

—
Reply to this email directly or view it on GitHub
#4.

from admesh.

Should be no problem.

from admesh.

@gladk Could you do some testing please?

from admesh.

@gladk There is 0.98.0alpha released.

from admesh.

I'm getting warning about calling exit from openSUSE build tool even for the latest version (0.98.3):

[    9s] admesh-libs.x86_64: W: shared-lib-calls-exit /usr/lib64/libadmesh.so.1.0.0 exit@GLIBC_2.2.5
[    9s] This library package calls exit() or _exit(), probably in a non-fork()
[    9s] context. Doing so from a library is strongly discouraged - when a library
[    9s] function calls exit(), it prevents the calling program from handling the
[    9s] error, reporting it to the user, closing files properly, and cleaning up any
[    9s] state that the program has. It is preferred for the library to return an
[    9s] actual error code and let the calling program decide how to handle the
[    9s] situation.

from admesh.

Yes, the function that calls exit is still there, but it's called exit_on_error. I think it's handled pretty reasonable now given the mess this "library" is.

from admesh.