Hello, On Mon 14 Jul 2025 at 10:00am +01, Ian Jackson wrote:
> I don't think so. I think I'm just being Dr Error Handling again... Heh. > This code can fail due to (for example) the tag named by > last_debian_tag not existing, or having weird syntax. > > In that case, if the user supplied --quilt=, that's silently fine: we > failed to check the user's work, but the anomaly is presumably why the > user is passing that option. > > To put it in type threory terms in Rust syntax. > > Before: > fn determine_quilt_mode_automatically(...) > -> Result<QuiltMode, FatalError> > > After: > fn determine_quilt_mode_automatically(...) > -> Rdsult<Result<QuiltMode, CouldNotDetermineQuiltMode>, FatalError> > > This means that every program call needs to be considered for whether > failure of this program (or perhpas, *this kind* of failure of this > program) is "expected" (-> CouldNotDetermineQuiltMode, might be > silently ignored) or "unexpedcted" (-> FatalError, always crash). > > That is doable but it's not trivial. If the user doesn't supply a quilt mode option then it's always a fatal error if we can't find one from the history. Your point is that if they do supply one, then we need to distinguish between different possible failures to find one from the history, between those that should still be fatal errors and those which should be ignored because the --quilt option the user has passed is pseudo-overriding them? -- Sean Whitton
signature.asc
Description: PGP signature
