PR Review: The Errors Should Be Nurtured

I ran into the following in a PR that I recently reviewed. Take a look and try to figure out why I’m pointing these bits out:

Those are bad errors — bad in the sense that they are hiding information. Sure, in 90% of the cases, the user can just put it in the backup location or the restore location. This way, they know what the application is referring to. But the other 10% is looking at the exception from the logs, getting an “I got an error” support call and all sorts of other weird stuff.

In particular, one of the most annoying things is when the user and the application disagree on a relative path. For example, if the user believes that the relative path is based on one location and the application another, hilarity ensues. And not in a fun way.

A better way to prevent all of those would be to just include the actual locations (fully resolved, mind you) in the error. It doesn’t prevent support calls, but it does make them a lot easier to solve.