hmn
/
orca
5
Fork 2
Code Issues 21 Pull Requests 1 Packages Projects Releases Wiki Activity

Handle allocation errors in UI layer #155

New Issue
Open
opened 2023-10-04 03:42:46 +00:00 by ilidemi · 1 comment
ilidemi commented 2023-10-04 03:42:46 +00:00
Collaborator
Copy Link

UI currently calls arena functions without checking the result. It is reasonable to expect that 1MB of memory is enough for most cases but it would be nice to explicitly log an error and crash. This behavior should also be documented - in Zig arena allocation can return explicit errors, and UI functions don't expose errors which can make the user think it can't fail. API-wise, the UI code is better off without error propagation (except on init), it just needs to fail fast and document that it'll do so.

This came out of #154

UI currently calls arena functions without checking the result. It is reasonable to expect that 1MB of memory is enough for most cases but it would be nice to explicitly log an error and crash. This behavior should also be documented - in Zig arena allocation can return explicit errors, and UI functions don't expose errors which can make the user think it can't fail. API-wise, the UI code is better off without error propagation (except on init), it just needs to fail fast and document that it'll do so. This came out of #154
MartinFouilleul commented 2023-10-04 19:17:33 +00:00
Collaborator
Copy Link

See #154 (comment)
I'm not sure it's worth it returning allocation errors and handling them. I think it's better to leave it to the host to do an orderly shutdown. But maybe you had a specific scenario in mind. What would a user actually do with an allocation error in the UI?

See https://git.handmade.network/hmn/orca/pulls/154#issuecomment-2240 I'm not sure it's worth it returning allocation errors and handling them. I think it's better to leave it to the host to do an orderly shutdown. But maybe you had a specific scenario in mind. What would a user actually do with an allocation error in the UI?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
split_abort_dialog
zig_ffi
subprocess
fix_win_gles_vsync
disable-win32-vsync
fix_layout
docs-ben
vblank_notification
bytebox_integration
Labels
Clear labels   
macOS

   
windows
No Label
macOS
windows
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hmn/orca#155
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?