Replace unwrap() in UntrustedRlp Display impl

[lght]

Use match { ... } in place of unwrap().

[parity-cla-bot]

It looks like @lght signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[rphmeier]

disregarding errors while writing is bad. why not simply use expect instead of rewriting? Or even rewrite using for (i, item) in self.iter().enumerate() in the list case?

[lght]

why not simply use expect instead of rewriting?

The point of these fixes was to remove panics from UntrustedRlp handling, using expect would just reintroduce the same problem.

I was following the pattern from other error conditions in this section of code. Definitely open to suggestions for how to handle the errors without panicking.

[rphmeier]

sure, then I would recommend using an iterator as it will be cleaner:

write!(f, "[")?;
for item in self.iter() {
    write!(f, "{}", item)?;
}
write!(f, "]")?;

both approaches are only as broken as the implementation of fn at which would be pretty good to fuzz.

[lght]

I do like the conciseness of your solution. It does have the drawback of making the source of the error more obscure (now the .at() source is hidden behind the .iter() implementation).

Should there be a more specific error raised by untrusted_rlp.at() to make the error's origin more clear? Maybe an error type like "RlpItemAccessError" or "RlpItemDecodeErrorAtIndex"?

Currently the error resolves to RlpExpectedToBeData, which doesn't point to the .at() implementation at all. I was only able to track down the origin after looking through the code for a couple hours. Had the .at().unwrap() not been in the Display impl, it may have taken much longer.

fn at which would be pretty good to fuzz

I'm open to getting started on that, adding to the work started by @onicslabs.