[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
It's necessary to help partially comply with the big spec.
As Tritium implements more of the spec, the solution is to eliminate the Option return value in the example altogether. The Cursor mis-fires there only due to a disconnect between the glyphs rendered on the canvas and the underlying AST representing those characters. Today, it probably never misses, but due to the complexity of the spec and essentially infinite nesting possible under it, Tritium can't guarantee that yet and so chooses to move the cursor to the top of the document. That's almost certainly better than panicking for the user, and its probability is approaching zero but non-zero. It's getting there.
This approach lets you ship something that is made safe by surfacing errors as a user-visible glitch rather than crashing in release builds.
Pure and deterministic algorithms can have the luxury of having much more strict and concrete error handling strategies.
On the other hand, "promptly handling errors" sounds naive for large distributed systems where almost every call can fail for reasons unknown. Experience has already shown that exactly the opposite approach - just panic and restart the "service" (process in Erlang terms, but it's got nothing to do with Unix processes and is far more granular) can build extremely reliable systems. In conventional programming languages, that roughly corresponds to adding top-mid-level error boundaries (exception/panic handlers) at critical junctures.
But perhaps that's what you mean by "error bubbling nests shallowly"? No idea, since it's not exactly clear.
Of course, this is still a cursory description. I think various strategies by domain agree on general principles. There is likely a class of errors that is too likely and/or unsolvable, in which case whole-task-restarts are advisable. Within the task, there may be other kinds of errors that can and should reasonably be resolved. User interactivity is also relevant (e.g. is a user directly interacting with a task in the error state). Overall, this comes down to a few factors for each error, roughly: likelihood, severity, solvability. Errors should always be reported when possible and brought to the attention, if not fixed, of a capable supervisor, which eventually culimante at a person (e.g. user or sysadmin).
dafelst•3mo ago
If an operation is fallible, it should return an error type and make it the job of the caller to deal with that. Silently returning default seems like a disaster waiting to happen, ala On Error Resume Next (which indeed was a disaster to deal with).
Now if this panic handler, instead of silently continuing in release mode, invoked some sort of "save your work and restart" handler such that the user doesn't lose anything and the program would restart in a known-good state, that seems like it would be a sensible way of doing things.
piker•3mo ago
[I added a note [NOTE: this strategy should only be used where returning early or default would be obvious to the user and be consistent with the upstream handling of an Err or None value.]]
tracker1•3mo ago
Oh, and variables like a1...a34, etc. and the passwords themselves... Database table [Phone2] ... why/how/wtf?!? Nobody knows. That was a godawful mess I will never forget.