To make discussion about a way to handle IO errors less generic consider a hypothetical program that that reads some configuration files that have include statements and suppose that one of the included files could not be read due to bad permissions. Ideally a user should receive a message like that include statement in file foo.conf line 123 could not be processed due to bad permissions. In the real world, especially if the permission problem would not be anticipated by the developer, a typical program I suppose would behave like:
C - program terminates with an abort message about permission problems. The message may include the name of the file, but there would be no information about the location of that include statement or even that the error happened during parsing of config files. Java and Python - a stack trace will be generated with error message similar to the C case. To the developer the stack trace tells that it was generated during parsing of the include statement, but the user will have no clue. Go - I have not used the language, but my general impression is that no error will be generated. Instead the file will be read as an empty string. The question is can Rust provide such error handling so the ideal scenario can be implemented with minimal efforts? From a personal experience in Java the solution was to pass an extra Reporter interface parameter into most of the parser and IO supporting libraries and stop using exceptions. Various program components then implemented that interface to add information about error location and conditions. The Reporter interface also provided a way to query about the current error status. Surprisingly with this setup besides the extra reporter parameter the source was not clattered with return status checks as the code style became to report errors, but still return sensible defaults (like reading the file as empty string). This way the caller can proceed as if error would not happen, but the report would not be lost. As an added benefit reporting several errors became trivial. On 17 October 2013 21:59, Patrick Walton <pwal...@mozilla.com> wrote: > You make a good case that it happens less in Go, but I'm still not sold on > Go's error handling, given that it's fundamentally built on a model that's > known to be error-prone. We know that the flaw of error-code-based systems > without checked returns is that you can forget to handle errors. Go makes > this harder in many situations, but it has known holes when the function > returns nothing but an error or the function is invoked only for its side > effects. I don't see any reason why we should deliberately go with a system > with known flaws and failure modes when there are better alternatives > available. > > In other words: Why bet, as Go did, that the failure case won't happen much > in practice when we can adopt an error-handling strategy that rules it out > entirely? > > Florian Weimer <f...@deneb.enyo.de> wrote: >> >> * Patrick Walton: >> >> >>> On the other hand, Cindy Rubio-González's work shows that in the Linux >>> kernel, forgetting to handle error codes is *extremely* common. >>> >>> http://www.eecs.berkeley.edu/~rubio/ >>> >>> I don't see anything fundamentally different with Go's approach that >>> will lead to a different outcome. >> >> >> The kernel usually passes results by storing them in an existing >> object because allocation by the callee is less efficient and >> impossible in many contexts. Go has garbage collection, and returning >> a new object and an error return value is the more common style. The >> result-plus-error case has a much better chance of being handled >> correctly. >> >> Go also has exceptions (for signaling certain errors). I'm not sur >> e >> if it deals with memory allocation failures gracefully. If it >> doesn't, that would eliminate a fair chunk of kernel error handling, >> too. >> >> So in short, Go is quite different. :-) > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
