This approach is brittle to upstream code changes, and I don't think it should be used, but at least there is an effort to avoid catastrophic behavior (unlike Linus's philosophy for Linux). Both panicking and arbitrarily-nested error bubbling are more standard and recommended, but I think they are still suboptimal, mainly for code quality/maintainability, and should be phased out gradually. I think the viable methods for robust software are promptly handling errors or making errors unrepresentable. To promptly handle errors, the program should be structured such that error bubbling nests shallowly. Unrepresentable errors work within type systems or formal verification, such as the classic advice of "parse, don't validate"[0], giving no way to speak of an error state (so hopefully a cosmic ray never causes it!). These latter approaches are more ideal, but can be a pain to implement.
Yes, this is a somewhat pragmatic approach and perhaps that should have been made clearer.
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.
I must be missing the point here, because this feels like bad advice. Calls like `panic` and `expect` and `assert` are there to uphold invariants, i.e. to deal with things that should never happen unless there is a logic error that invalidates the assumptions you hold about your program. It means "if you got here, I (the programmer) probably fucked up badly".
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.
Actually that’s a fair point that should be clarified. These would be in places where practically panicking cannot happen, so you be tempted to swallow the Error and continue. But they should only be used where recovering with Default is okay.
[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.]]
First day at a new job: There's a bug in the password check at login... anyone who enters a valid user id can login... (on error resume next)
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.
This approach is brittle to upstream code changes, and I don't think it should be used, but at least there is an effort to avoid catastrophic behavior (unlike Linus's philosophy for Linux). Both panicking and arbitrarily-nested error bubbling are more standard and recommended, but I think they are still suboptimal, mainly for code quality/maintainability, and should be phased out gradually. I think the viable methods for robust software are promptly handling errors or making errors unrepresentable. To promptly handle errors, the program should be structured such that error bubbling nests shallowly. Unrepresentable errors work within type systems or formal verification, such as the classic advice of "parse, don't validate"[0], giving no way to speak of an error state (so hopefully a cosmic ray never causes it!). These latter approaches are more ideal, but can be a pain to implement.
[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Yes, this is a somewhat pragmatic approach and perhaps that should have been made clearer.
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.
I must be missing the point here, because this feels like bad advice. Calls like `panic` and `expect` and `assert` are there to uphold invariants, i.e. to deal with things that should never happen unless there is a logic error that invalidates the assumptions you hold about your program. It means "if you got here, I (the programmer) probably fucked up badly".
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.
Actually that’s a fair point that should be clarified. These would be in places where practically panicking cannot happen, so you be tempted to swallow the Error and continue. But they should only be used where recovering with Default is okay.
[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.]]
First day at a new job: There's a bug in the password check at login... anyone who enters a valid user id can login... (on error resume next)
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.