Error handling: Don't call exit(n) inside libtesseract

[amitdo]

https://github.com/tesseract-ocr/tesseract/blob/01535706ecd11a495f9f6e65ee0118b3537a115a/src/textord/strokewidth.cpp#L121-L128

https://github.com/tesseract-ocr/tesseract/blob/2a37f5dd6226156bf32e60d1ae0209a383af4843/src/classify/intproto.cpp#L231-L238

https://github.com/tesseract-ocr/tesseract/blob/912c9978dacf9f7a7cc97ba9a906b40e3df8fc09/src/dict/permdawg.cpp#L111-L121

[stweil]

Are there examples which trigger those exits? That would help testing fixes this issue.

[amitdo]

No, I don't have examples which trigger those exits.

[jbarlow83]

@stweil Any call to exit() from code intended for use in a library is a bug - it doesn't really matter how to trigger them. For a GUI that binds libtesseract, the application will be nuked from orbit by exit() and probably won't be able to get an error message to user.

Ideally Tesseract would just throw an std::exception because those exits are really deep in the call stack. Are exceptions still forbidden? The standard library can and does throw exceptions, they're already de facto in use.

If we can't use exceptions, the thing to do is define a function pointer that defaults to exit()...

void (*tesseract_exit)(int error_code) = exit;

...and add an API call that lets the application provide its own exit handler. That way the application can throw an exception or do whatever makes sense in context.

[amitdo]

The ban on exceptions came from Google coding rules. Since Ray left this project years ago, we don't have to be limited by their internal coding standards.

@stweil, should we use exceptions instead of these exit() calls?

[stweil]

I am not sure about the implications on performance (which is critical for Tesseract training and recognition) when exceptions are used. Calling exit or maybe better abort in case of an internal software bug is fine for me.

[jbarlow83]

C++ exceptions are zero cost when the exception does not occur.