4 ms·

For application code, you can change the behavior of Rust panics. Although I haven't verified this myself, I fully expect that you can achieve saving a documen

For application code, you can change the behavior of Rust panics. Although I haven't verified this myself, I fully expect that you can achieve saving a document and exiting gracefully. The distinction is that panicking should (almost) never be used for recoverable errors. You can, but that's not idiomatic and would only be appropriate within the confines of your own application. Recoverable errors in Rust should be handled by return values, typically via either Result or Option. This is unlike all the other options I listed (except Go, and C++ with exceptions disabled), where it is idiomatic to use exceptions to handle recoverable errors. In theory, (strictly) checked exceptions are equivalent (isomorphic) to error codes as an error handling mechanism. But as soon as unchecked exceptions are allowed, it all falls apart and you must contend with the problem of "invisible control flow". Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. The Joe Duffy blog post I linked to earlier compares various error handling methods, including checked exceptions. It's very long, but interacting deeply with this blog post helped me to level up my understanding of error handling. FWIW I did a presentation on Duffy's article for the San Diego chapter of Papers We Love: https://www.youtube.com/watch?v=GwPBC4mWfFQ https://www.youtube.com/watch?v=GwPBC4mWfFQ

jcelerier 5y ago
> You can, but that's not idiomatic I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. The only thing that matters is the language spec - everything that fits in there is kosher. Idioms just create pointless fights and tabs vs spaces situations where there doesn't need to be any. > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. no, you just choose to ignore it. I can also write C++ code with throw and no try..catch and that will give the same result (as I pretty much use exceptions like one would use panic! in rust). I don't know anyone who would say that this is a good idea. My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues, and sometimes, when it turns out that an issue has a way to be recovered (or that maybe it doesn't matter), then someone gets a try..catch block. Like most articles about exceptions, that Joe Duffy post talks about the problem of "where the control flow goes". I've written my first lines of C++ something like 17-18 years ago now and not once it has actually been an issue. Consultants sure do love selling it as one though.
- rectang 5y ago
  > I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. My response is that adherence to common idioms is simultaneously beneficial and harmful. It is beneficial because shared assumptions and shared understanding facilitate cooperation, yet it is harmful because it impedes innovation. Whether it is more beneficial or more harmful on balance depends on the situation and on individual taste. I'd like to think that our perspectives are compatible. > > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. > no, you just choose to ignore it. I guess you could characterize things that way. For example, in the Rust library code I write, I choose to ignore certain unrecoverable errors — e.g. out-of-memory panics from allocating ordinary sized objects, even though such panics can theoretically occur. But the distinction here is that I also expect e.g. invalid argument values or "file not found" errors to be handled via Rust's Result type. I don't choose to ignore such events — I expect all recoverable errors to be handled via visible control flow, where you can identify every location in the code that such an error might occur. This makes it easier to reason about control flow for all circumstances save unrecoverable errors. > My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues Yes, that's an Anders-Hejlsberg-endorsed way of doing things. "The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler." https://www.artima.com/articles/the-trouble-with-checked-exceptions#part2 https://www.artima.com/articles/the-trouble-with-checked-exc... I think the preference for one way of doing things can depend on what problem domain you work in. That approach is highly suitable for applications programming. (Duffy has done a lot of work on operating systems; my biggest projects have been libraries.) > Consultants sure do love selling it as one though. EDIT: I'm not very happy about that take, and I originally wrote up a lengthy response — but it turns out I had incorrectly recalled that this was not the first such interaction we've had. (I was recalling an obnoxious post from a different European with the first initial "j"). I've deleted my response because it's OT and not worth dealing with if it's not something recurring.

jcelerier 5y ago

> You can, but that's not idiomatic I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. The only thing that matters is the language spec - everything that fits in there is kosher. Idioms just create pointless fights and tabs vs spaces situations where there doesn't need to be any. > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. no, you just choose to ignore it. I can also write C++ code with throw and no try..catch and that will give the same result (as I pretty much use exceptions like one would use panic! in rust). I don't know anyone who would say that this is a good idea. My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues, and sometimes, when it turns out that an issue has a way to be recovered (or that maybe it doesn't matter), then someone gets a try..catch block. Like most articles about exceptions, that Joe Duffy post talks about the problem of "where the control flow goes". I've written my first lines of C++ something like 17-18 years ago now and not once it has actually been an issue. Consultants sure do love selling it as one though.

rectang 5y ago
> I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. My response is that adherence to common idioms is simultaneously beneficial and harmful. It is beneficial because shared assumptions and shared understanding facilitate cooperation, yet it is harmful because it impedes innovation. Whether it is more beneficial or more harmful on balance depends on the situation and on individual taste. I'd like to think that our perspectives are compatible. > > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does. > no, you just choose to ignore it. I guess you could characterize things that way. For example, in the Rust library code I write, I choose to ignore certain unrecoverable errors — e.g. out-of-memory panics from allocating ordinary sized objects, even though such panics can theoretically occur. But the distinction here is that I also expect e.g. invalid argument values or "file not found" errors to be handled via Rust's Result type. I don't choose to ignore such events — I expect all recoverable errors to be handled via visible control flow, where you can identify every location in the code that such an error might occur. This makes it easier to reason about control flow for all circumstances save unrecoverable errors. > My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues Yes, that's an Anders-Hejlsberg-endorsed way of doing things. "The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler." https://www.artima.com/articles/the-trouble-with-checked-exceptions#part2 https://www.artima.com/articles/the-trouble-with-checked-exc... I think the preference for one way of doing things can depend on what problem domain you work in. That approach is highly suitable for applications programming. (Duffy has done a lot of work on operating systems; my biggest projects have been libraries.) > Consultants sure do love selling it as one though. EDIT: I'm not very happy about that take, and I originally wrote up a lengthy response — but it turns out I had incorrectly recalled that this was not the first such interaction we've had. (I was recalling an obnoxious post from a different European with the first initial "j"). I've deleted my response because it's OT and not worth dealing with if it's not something recurring.