MprisPlayer::new panics on failure
If DBus access cannot be obtained, MprisPlayer::new
will panic. This makes it impossible for the caller to catch and gracefully handle the failure. I would prefer if MprisPlayer::new
were modified to return Result<Arc<MprisPlayer>, _>
instead of Arc<MprisPlayer>
. This is an API-compatibility-breaking change; existing programs that want a panic can call MprisPlayer::new().unwrap()
instead of just MprisPlayer::new()
, and will then behave just like before.
An alternative approach would be to make a new associated method that returns Result<Arc<MprisPlayer>, _>
, move all the construction logic there, and change new
to be a wrapper around it:
fn new() -> Arc<MprisPlayer> {
MprisPlayer::try_new().unwrap()
}
This would allow previous programs to continue working, as this is not an API-compatibility-breaking change. It's less idiomatic, but it still works.
Example output from a program failing to access DBus:
dbus[72876]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: D-Bus error: Not enough memory (org.freedesktop.DBus.Error.NoMemory)', /Users/<redacted>/.cargo/registry/src/github.com-1ecc6299db9ec823/mpris-player-0.6.0/src/mpris_player.rs:75:77
(I am told that the DBus library reports "Not enough memory" when it can neither connect to nor start the daemon. Which is strange.)