7 ms·
Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code: 1. Error handling. The lack of built-in support for mul
by ww520 10y ago
Speaking of removing friction, there are three areas that have caused me grief when I wrote Rust code:
1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result<Value, Error1 | Error2 | Error3> would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too.
2. Lack of stack trace when an error occurs. Now that stacktrace starts when panic!() is called, which is kind of late.
3. Better support for conversion between &str and String. Dealing with strings is so prevalent in programming that making it easier to work with the two types would be a huge boost to productivity.
Edit: another item
4. Support of partially applied function , i.e. bind a subset of arguments to the function pointer. Currently there's no way to bind the self argument to the Option/Result chaining calls. Basically the Option/Result chain (.and_then, .map, etc) only carries forward the value of Option/Result and nothing else. It would be nice put partially applied function in the chain. e.g. result.and_then(self.func1) where func1 has the self argument bounded. Or in more general form, result.and_then(func1("param1", param2, _)) where func1's first and second parameters have been bounded up front and the value of result will be passed in as the 3rd parameter.
- yarper 10y agofor 1. there's map_err(..) which accepts a closure e.g. `try!(foo().map_err(|e| format!("{}", e.thing)));`
- JoshTriplett 10y ago> 1. Error handling. The lack of built-in support for multi-error or error union in Result is painful in dealing with different types of error in a function. Support for Result<Value, Error1 | Error2 | Error3> would be helpful. Or may be support for easily converting one type of error to another. Now there's lots of boiler plate code to deal with error conversion. Error chaining would be nice, too. There are a couple of crates that support this; personally, I recommend the "error-chain" crate. However, I do wish that Rust promoted the most capable of those to the standard library. > 2. Lack of stack trace when an error occurs. Now that stacktrace starts when panic!() is called, which is kind of late. error-chain provides that. > 3. Better support for conversion between &str and String. Dealing with strings is so prevalent in programming that making it easier to work with the two types would be a huge boost to productivity. Can you give some specific examples of cases you've found cumbersome? String has a Deref instance for &str, so taking a reference to a String automatically works as a &str. You can also call .as_str(). Going in the other direction, you can call .to_string() to make a copy of a &str as a new String.
- ww520 10y ago1. Some of the 3rd party error chain libraries help somehow but they don't help to remove the boiler plate when dealing with different types of error. I just want to be able to do: fn func1() -> Result<MyStruct, Error1 | Error2> { let foo = foo()?; // which can return Error1 let bar = bar()?; // which can return Error2 ... } 2. Error chain only shows the stack where I explicitly add it to the chain. Anything underneath is not shown. All these should be done by the runtime instead of forcing the developers to add code to handle it. Also, error handling is so prevalent in Rust. If error chain is the way to go, make it as built-in. As right now, everyone has to hit a brick wall with Result, and then hunt around for the same solution. 3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit and automatic if the type expects a String while a &str is passed in.
- JoshTriplett 10y agoI completely agree that Rust ought to build in support for the error-chaining pattern. I think I'd still prefer to have a named type, but the standard library should provide a standard way to construct that type. > 3. It's the other way around &str to String, having to call .to_string() everywhere. Make it implicit if the type expects a String while a &str is passed in. You can't turn a reference like &str into an owned type like String without making a copy, and Rust doesn't do implicit copies (among many other reasons, because doing so would make it harder to notice code patterns that will lead to poor performance). So you'll always have to have some explicit indication that you want to make a copy. In general, most functions should accept &str parameters rather than String, for exactly that reason; you should rarely run into functions that want a String. You can also use the "Cow" type if you want to support both owned and borrowed strings in the same structure.
- bvinc 10y ago> Support for Result<Value, Error1 | Error2 | Error3> would be helpful. Or may be support for easily converting one type of error to another. It sounds like you want to create a new error type that's an enum of Error1, Error2, Error3 and then just implement the From traits. Then you can use ? with no boilerplate error handling. I'm sure you've already considered this though. Why wouldn't that work for you?
- progval 10y agoDeclaring the new enum and implementing it are the boilerplate.
- ww520 10y agoLots of typing and mental overload. Since we are talking about ergonomics and reducing friction, it would be good to make Result handling easier.
- JelteF 10y agoThe From trait can be derived using my derive_more crate. That would at least decrease the boilerplate a bit. http://jeltef.github.io/derive_more/derive_more/ http://jeltef.github.io/derive_more/derive_more/
- ice109 10y agoI don't understand there are no stack traces unless you use a library?