Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

PR Review: The Errors Should Be Nurtured

DZone's Guide to

PR Review: The Errors Should Be Nurtured

A better way to prevent this would be to just include the actual locations in the error. It doesn’t prevent support calls, but it does make them a lot easier to solve.

Free Resource

Maintain Application Performance with real-time monitoring and instrumentation for any application. Learn More!

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:

image_thumb[2]

image_thumb[3]

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.

Collect, analyze, and visualize performance data from mobile to mainframe with AutoPilot APM. Get a Demo!

Topics:
performance ,pull requests ,errors

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}