Consider error handling paths.
(e.g. trying to convert a 16-bit unsigned integer into a 32-bit signed integer can't fail, that always works so its error type is Infallible, whereas trying to convert a 32-bit signed integer into an unsigned one clearly fails for some values, that's a core::num::TryFromIntError you need to handle)
So we're left only with errors which don't happen. But who says? On my workload maybe the profile image file doesn't exist 0% of the time since I'm actually making the image files, so of course they exist, but in your workload the user gets to specify the filename and so they type it wrong about 0.1% of the time, and in somebody else's workload the hostile adversary spews nonsense filename values like "../../../../../etc/passwd" to try to exploit bugs in some PHP code from 15 years ago, so they see almost 10% errors. What would we learn from a "general profile"? Nothing useful.
$ process Some Image Name.png
Could not find file “Some”
$ process “Some Image Name.png”
Done.
... Urg, that.
If I ever implement a bespoke file system format, it is going to be encoding-level impossible to represent file names with spaces. Not FAT-style[0] "the spec says to replace that with a underscore" or something, but more "the on-disk character encoding does not contain any sequence of bits that represents space".
0: (non-ex-)FAT stores filenames in all caps, but the data of disk is ASCII, so you can just write lowercase letters in the physical directory entries. (I've seen at least one FAT implementation that actually uses that to 'support' lowercase filenames.)
(I had someone ask for the possibility of being able to choose older versions of Unicode in my library to handle his use case with clusters in a terminal app, but on further investigation to what he was trying to do, I discovered that it was a misunderstanding about how grapheme clusters work and in fact would not do what he wanted it to do.)