221–230 of 329 posts
Earlier quoted context omitted.
I'd expect 'on_error' to take a function as a callback, not a string. But yes, a better named function could be added
expect[ing_error]("could not open the file")
Earlier quoted context omitted.
I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.
The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it wil…
No. They are usually logged. The difference is that with exceptions, the logging will occur at a higher level and be done uniformly while in Rust you'll have to explicitly thread the error through the call stack manually to log it at a higher level.
Earlier quoted context omitted.
In case someone cares to understand what this means: - "An Error trait" means that when you define a new type that will store error information, you have to define how it implements the Error interface. - "appropriate From impls"... you are trying to wrap a number of error types in your own special error type, you need to tell the compiler how to convert another specific type into your type new type. There is an inte…
Sorry, I'm trying very hard to learn Rust, and I'm willing to accept a lot of its restrictions, but this didn't clear anything up. Why does every library implement its own Error type? It feels like reinventing the wheel, and it takes a lot of boilerplate code. If you need to distinguish different kinds of errors, why not, for example, have a lot of useful pre-defined error types like Python does?
Now, in most cases, callers don't care at all about which specific error happened. They just want to print the error and be done with it. And that works just fine, because of the error handling machinery. But if you do want to drill down, then the option is there for you.
Earlier quoted context omitted.
In case someone cares to understand what this means: - "An Error trait" means that when you define a new type that will store error information, you have to define how it implements the Error interface. - "appropriate From impls"... you are trying to wrap a number of error types in your own special error type, you need to tell the compiler how to convert another specific type into your type new type. There is an inte…
Sorry, I'm trying very hard to learn Rust, and I'm willing to accept a lot of its restrictions, but this didn't clear anything up. Why does every library implement its own Error type? It feels like reinventing the wheel, and it takes a lot of boilerplate code. If you need to distinguish different kinds of errors, why not, for example, have a lot of useful pre-defined error types like Python does?
Earlier quoted context omitted.
Unfortunately 90% of them will be outdated/wrong/unsafe. Being backward compatible with 30 years of code means you're unlikely to find the right answer for the present. And worse, you won't know it.
You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.
Earlier quoted context omitted.
I don't know if that's quite true. While Rust is very deep, I've found that you can get quite far with a few crucial pieces of info (note that I don't speak about generics or macros; haven't worked a lot with them): * All variables are expected to be sized. So, learn what's sized and what isn't. * Understand traits and how they add functionality to types. Have a small dictionary of common ones (From, Into, Debug, etc…
Any links or ideas on how to get started with some of these? Understanding traits and knowing common ones is as trivial as reading the Rust Book, but ideas like "write blanket implementations" and "encapsulate ownership details" are less easy to find.
As for "encapsulate ownership details". Hard to describe, but...let me point to Tokio [3] again. In Java if you wanted to share an IO reader/writer with two different objects you'd use the same type and pass the same reference to both owners. In Rust, the same idiom would require the wordy use of `Arc>` or `Rc>`. I hope we can both agree that that's frustrating. An alternative (as demonstrated by Tokio's `split` method) is to separate your base type into two other types - reader and writer - that can be owned independently. No more externally-visible ref counting. Of course, this isn't possible in all scenarios: there absolutely are times when you don't have a clean separation of types and have to ref count; but, avoid it if you can.
I learned all of this by poking into libs, asking a ton on the IRC channels (everyone is super friendly) and failing a lot. Any errors are my own. Hope that helps!
[1] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...
[2] https://doc.rust-lang.org/src/std/error.rs.html#281
[3] https://github.com/tokio-rs/tokio-io/blob/master/src/lib.rs#...
Earlier quoted context omitted.
Depending on where it crashed, the Python script would raise an exception. It would most likely be an `IoError`, `KeyError`, or `ValueError`. Then it would show an error message with a line number, column number, and traceback. Using a debugger would allow you to step backwards through the traceback to determine if the error was caused by something further up the line or where the exception was raised. All of Python'…
So the Python script proposed in this article really just skips all error checking and will die just the same as the hard unwrapped Rust version with the only benefit it actually produces a more user-friendly error and it doesn't look as ugly. I can't edit my reply anymore but the question was actually meant to be rhetorical rather than I really wanted an answer.
Only if the programmer chooses to not handle exceptions, which is bad practice.
>and will die just the same as the hard unwrapped Rust version with the only benefit it actually produces a more user-friendly error and it doesn't look as ugly.
No, it won't die unless the programmer wants it to. In Python you can catch an exception and continue the operation in a different manner. In fact, it is common practice in a lot of Python libraries to use exceptions to determine the presence of data and act according to whether or not the exception occurred. If I'm not mistaken, I believe that this is common practice in most languages that utilize the exception pattern.
> I can't edit my reply anymore but the question was actually meant to be rhetorical rather than I really wanted an answer.
Well, you seem to not know a lot about exception handling in Python, so I hope I was at least a little helpful.
Earlier quoted context omitted.
Nim. It lets you get stuff done without having to drink the provably correct kool-aid.
GC, though, an a much, much smaller community.
Earlier quoted context omitted.
> Case in point: the example in the article from the rust documentation that converts errors to strings just to forward them This section: - Shows you how to define your own Result types. They have chosen a String as an example of what you could use as an error type. In practice nobody uses "String" as an error type. - Concludes by defining a custom error type to use instead of a String. I guess you didn't read that…
Using String as an example error type seems like a bad choice if nobody actually uses it in practice, though -- it's just leading you down the garden path. Personally I found the error handling section of the documentation confusing and frustrating -- it works through three or four different approaches pointing out issues with them as it goes, and it's hard to tell when it's discussing a simple-but-wrong approach as…
With that said, thank you for the feedback. When I circle back around to it, I'll make sure to put more emphasis on The Right Way. The conclusion already has some of it, and the case study is supposed to show the progression in action, but perhaps more is needed.
I will let others focus on more targeted advice, since one huge chapter on error handling is only part of the story. The purpose of the error handling chapter is start with someone who might not even know what `Option` is, and take them all the way through `try!`, the `Error` trait and automatic `From` conversions from first principles. More than that, it's supposed to teach you why using `String` or `Box` for your error type can be bad, even if it is ludicrously convenient.
Rust is a young language. I expect error handling idioms to evolve. Evolution doesn't mean something isn't ready to be used, because all languages evolve in some way.
One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…
I think it is 100% the case that the best way to learn Rust is to be on the IRC channel (#rust or #rust-beginners, either is fine for beginners but the latter is unlogged and more focused if you prefer) and ask lots of questions and also lurk. I'm not sure if that's good in absolute terms for the language, but it's very helpful. (Which probably means your first project should be something open-source so you can share…
My time never really allows me to be on IRC regularly. Point being that if you can't get on IRC, I don't think it's necessary.
And honestly, error handling was the most difficult thing to understand, until you start groking why sized types are required as return types from functions and that every function call up the stack requires its callees to compensate for all it's error possibilities.
error_chain! has made this all so much better.