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

Returning incorrect result in handle_event results in silent error #131

Open
thbar opened this issue May 26, 2024 · 1 comment
Open

Returning incorrect result in handle_event results in silent error #131

thbar opened this issue May 26, 2024 · 1 comment

Comments

@thbar
Copy link
Contributor

thbar commented May 26, 2024

Hi!

I discovered today something that caught me quite off-guard and which I find quite error-prone: if one returns, for instance, state, or "hello" instead of {:ok, state} in their implementation of handle_element, no error is raised.

I checked the documentation:

https://github.com/qcam/saxy/blob/dce77bfd4664f1ab90f76d3c847224dbbfabe820/lib/saxy/handler.ex#L15C1-L22C34

Returning {:ok, new_state} continues the parsing process with the new state.

Returning {:stop, anything} stops the prosing process immediately, and anything will be returned.
This is usually handy when we want to get the desired return without parsing the whole file.

Returning {:halt, anything} stops the prosing process immediately, anything will be returned, together
with the rest of buffer being parsed. This is usually handy when we want to get the desired return
without parsing the whole file.

I have no idea at this point if this is easy to fix or not!

@thbar
Copy link
Contributor Author

thbar commented May 26, 2024

Re-reading my issue, I realise this may be done on purpose, yet I'm concerned that just bogusly returning state instead of {:ok, state} could result into very incorrect programs, and would prefer an error here.

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

No branches or pull requests

1 participant