Re:Looking into Odin and Zig
by aidenn0 on Tuesday September 07, 2021 @02:29PM
(#28448155)
> Running various callbacks or whatever is still overthinking the problem, similar to throwing exceptions. There's still a preconceived notion that anybody would want to (or could) handle a certain state right then and there.
Sometimes you want to and can, other times you don't. Sometimes you want to log some state that will be destroyed when you unwind the stack. Not being allowed to handle an exception before unwinding the stack is a hindrance.
The common case is that you will unwind the stack; lisp even has a form that does so (handler-case vs handler-bind) because it is so common.
"Where" an exception is handled is two dimensional. There is "where in the source" and "when at runtime" Most exception systems unnecessarily couple the two. If you make an API call that you know will cause a network request somewhere downstack, and at that point in the code instruct it to retry up to 3 times when a connection-refused exception occurs, then you have a usable exception system.
If you can't do that, then just give up and return errors.
Sometimes you want to and can, other times you don't. Sometimes you want to log some state that will be destroyed when you unwind the stack. Not being allowed to handle an exception before unwinding the stack is a hindrance.
The common case is that you will unwind the stack; lisp even has a form that does so (handler-case vs handler-bind) because it is so common.
"Where" an exception is handled is two dimensional. There is "where in the source" and "when at runtime" Most exception systems unnecessarily couple the two. If you make an API call that you know will cause a network request somewhere downstack, and at that point in the code instruct it to retry up to 3 times when a connection-refused exception occurs, then you have a usable exception system.
If you can't do that, then just give up and return errors.