Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle ZXingError class in iOS wrapper #877

Merged
merged 2 commits into from
Dec 25, 2024

Conversation

GUIEEN
Copy link
Contributor

@GUIEEN GUIEEN commented Dec 23, 2024

The ZXing::Error class does not inherit from std::exception, causing the app to crash when this error is thrown while using the iOS wrapper. I’m not sure why it doesn’t inherit from std::exception, but other wrappers in other languages handle these exceptions.

@GUIEEN GUIEEN force-pushed the feature/catch-zxing-error branch from f919288 to 3087469 Compare December 23, 2024 05:48
axxel added a commit that referenced this pull request Dec 24, 2024
... ODDataBarExpandedBitDecoder.cpp. This is related to #877.
@axxel
Copy link
Collaborator

axxel commented Dec 24, 2024

I’m not sure why it doesn’t inherit from std::exception, but other wrappers in other languages handle these exceptions.

This question got me baffled for a moment. I thought, this is an excellent question and why the hell did I not inherit Error from std::exception?!? After looking through the use cases of Error and my memory, I remembered what was behind this decision. To not forget again and for others to be detectable, I decided to add a comment to the Error.h file.

Now to your specific change here: As described in my mentioned comment, Error objects are not meant to be thrown from inside ReadBarcodes, if they are, then this should be considered a bug in the library. Did you encounter such a case prior to introducing #878 ?

Note that the two other implementations you linked to are not catching Error objects but simply anything.

@GUIEEN
Copy link
Contributor Author

GUIEEN commented Dec 24, 2024

Note that the two other implementations you linked to are not catching Error objects but simply anything.

You're right. Those are catching everything, but basically, they prevent the app from crashing in the case of a ZXing::Error being thrown.

if they are, then this should be considered a bug in the library. Did you encounter such a case prior to introducing #878 ?

Yes, it’s difficult to reproduce. It happens randomly, but the iOS app I'm working on crashes due to a ZXing::Error and an assertion failure.

To quickly fix my app, I decided to catch the ZXing::Error and stop using assertions, as the unexpected crash is not desirable. It may not be the preferred solution, since it simply catches the error, but this is missing in the iOS wrapper.

@axxel
Copy link
Collaborator

axxel commented Dec 24, 2024

As described in the comment, the library is not supposed to throw Error objects up the stack into user/wrapper code. Therefore, I'd consider it to be wrong/misleading if we merged this PR as is. I see a point in adding a catch-all clause, to prevent any crash due to unhandled exceptions. Would you be interested in modifying your PR accordingly?

As for the assertions, they (should) disappear in a release built.

@GUIEEN
Copy link
Contributor Author

GUIEEN commented Dec 25, 2024

Sure. I updated the code to catch any thrown objects.

@axxel axxel merged commit 0dfa36b into zxing-cpp:master Dec 25, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants