PR Reviewthe errors should be nurtured
I run into the following in a PR I recently reviewed. Take a look and try to figure out why I’m pointing this bits out:
Those are bad errors. In the sense that they are hiding information. Sure, in 90% of the cases the user just put it the backup location or the restore location, so they know what the application is referring to. But the other 10% is looking at the exception from the logs, having “I got an error” support call or all sort of weird stuff.
In particular, one of the most annoying things is when the user and the application disagree on a relative path. If the user believes that the relative path is based on one location and the application another, hilarity ensues. But not in a fun way.
A better way to prevent all of those would be to just include the actual locations (fully resolved, mind) in the error. It doesn’t prevent support calls, but it does make them a lot easier to solve.
More posts in "PR Review" series:
- (19 Dec 2017) The simple stuff will trip you
- (08 Nov 2017) Encapsulation stops at the assembly boundary
- (25 Oct 2017) It’s the error handling, again
- (23 Oct 2017) Beware the things you can’t see
- (20 Oct 2017) Code has cost, justify it
- (10 Aug 2017) Errors, errors and more errors
- (21 Jul 2017) Is your error handling required?
- (23 Jun 2017) avoid too many parameters
- (21 Jun 2017) the errors should be nurtured
Comments
The first ArgumentException should say (sarcasm): "Backup location doesn't exist. I will not say you what the location is because telling you something that you must know has no sense. And I will not create it for you because if you are lazy, I'm even lazier"
I will not create it for you, because I'm not qualified to judge whether you made a mistake or not.
<grammarnazi>hilarity ensues</grammarnazi>
Thanks, fixed
Comment preview