This year is my second atempt to get into rust. Therefore I created a small "cross platform tray application" which gets a random wallpaper from "wallhaven.cc" and sets it as the current desktop background. Some parameters can be adjusted through a config file.
Now my question: I created a error.rs file which implements a custom error type "FreshwallError". This error implements every possible "from" trait for the different errors which could occur. I noticed that I somehow reimplemented the display of errors from different libraries which I use. This seems to be necessary, because my main function could return the "FreshwallError". Is it possible to return different error types without implementing all "from" traits for every possible error type? Or is this the common way to do this kind of thing?
Right now your error is kinda stringly-typed and is more or less emulating the functionality that you'd get by using an Error trait object, so maybe it would make more sense to simply do that instead.
If you wanted to go that route then you'd change your main function and other functions to return Result<(), Box<dyn std::error::Error> instead of the custom error type.
dyn is the new, recommended way for how to write out that you're using a trait object. So Box<dyn Trait> and Box<Trait> are the same thing and are both performing dynamic dispatch. The reason the dyn keyword was added is to make it more clear when this dynamic dispatch is happening.
I read a bit about static dispatch and dynamic dispatch. Is it correct, that it is better for performance to use an "own" error object? Because the compiler would then be able to do static dispatching?
One more question: I saw, that one of the error objects in a library I use doesn't implement the Error trait. Therefore the compiler not able to dispatch it to this trait. What would be the best way to overcome this problem? A own error object? Or is there a better way?
Static dispatch isn't necessarily better 100% of the time. Unboxed error types occupy space on the stack like any other struct or enum, and it can happen that repeatedly copying larger error types around becomes more expensive than going through dynamic dispatch. This isn't really something you can eyeball though. If the performance difference is something that matters enough then you would need to profile your application and find hard numbers to decide which method works best.
As for the error type that doesn't impl Error, you probably could convert it into your own error type if you like. For example, you could make your own enum that wraps around all of the other enums that you receive. Or you could still convert the errors to some other internal representation, but you'd want it to be a bit more robust than one String to rule them all.
Alternatively you could make a PR to the other library so that their error impls the Error trait so that you can keep doing dynamic dispatch.