Update README with error codes table, return types, and expanded example#71
Conversation
- Add Returns column to Lifecycle table (void / OkjError) - Expand Quick Start to demonstrate okj_get_array, okj_get_object, and all three okj_count_* utilities - Add Error Codes section listing all 20 OkjError values with their integer values and descriptions https://claude.ai/code/session_01Uq4UP4zHprGZm7FWhVpUJY
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 092733ee75
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | `OKJ_ERROR_BAD_NUMBER` | 8 | Key not found or value is not a number | | ||
| | `OKJ_ERROR_BAD_OBJECT` | 9 | Key not found, value is not an object, or member count exceeds `OKJ_MAX_OBJECT_SIZE` | | ||
| | `OKJ_ERROR_BAD_STRING` | 10 | Key not found or value is not a string | |
There was a problem hiding this comment.
Clarify BAD_ meanings for parser return codes*
The new error table describes OKJ_ERROR_BAD_NUMBER/OKJ_ERROR_BAD_STRING only as getter failures (“key not found or wrong type”), but okj_parse() also returns those same codes for malformed JSON literals (see src/ok_json.c where parse sets OKJ_ERROR_BAD_NUMBER at line 1432 and OKJ_ERROR_BAD_STRING in the string parser path around lines 1202-1254). With the current wording, users handling parse failures can misclassify syntax/data-format errors as lookup issues and apply the wrong recovery logic.
Useful? React with 👍 / 👎.
https://claude.ai/code/session_01Uq4UP4zHprGZm7FWhVpUJY