Skip to content

Conversation

@jepler
Copy link

@jepler jepler commented Nov 11, 2020

I wrote this code for audioio but that's not ready for inclusion, and @microdev1 says it would be useful in their work.

I wrote this code for audioio but that's not ready for inclusion, and
microDEV says it would be useful in their work.
@microdev1
Copy link
Collaborator

Thanks! @jepler. One question, what parameters are you using to categorize an error of type ESP_ERR_ to be eligible for inclusion.

@jepler
Copy link
Author

jepler commented Nov 11, 2020

@microdev1 I think that any error that would plausibly arise from user code we would want to include. I just did the ones in the "main" error header, esp_err.h.

@tannewt tannewt self-requested a review November 12, 2020 01:23
Copy link
Member

@tannewt tannewt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! Would you mind using a subclass of OSError instead of OSError itself? That way we can differentiate a bit more. There is an example with the espidf.MemoryError already.

msg = translate("Generic Failure");
break;
case ESP_ERR_NO_MEM:
msg = translate("Out of memory");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jepler
Copy link
Author

jepler commented Nov 12, 2020

Are you thinking just one additional class for any esp error? if not, can you let me know what classes you're looking for?

@tannewt
Copy link
Member

tannewt commented Nov 12, 2020

@jepler Ya, one to start with in addition to the existing MemoryError. We can subclass the IDFError exception in the future if need be.

@jepler jepler closed this Jan 12, 2021
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.

3 participants