
Ask HN: Handle or Show Errors in an Application - NicoJuicy
Someone in my team is a huge fan of &quot;catching&quot; errors and pretending it&#x27;s works okay.<p>People should check the logs and see if there is something wrong. Data that is send through the stack is sometimes &quot;invalid&quot; because of all the handling.<p>I&#x27;m a fan of showing the error. Something goes wrong, it has to be fixed. And since something goes wrong, it may be shown in the frontend.<p>We both use logging of course :)<p>What is your preference?
======
lsiunsuex
Both

Detailed errors to log files or what have you

Friendly errors to the user.

If it's an internal project, I like to get specific. "Please contact the
developers at ext: xxxx and tell them this: ..."

If it's an internet facing / external user app / project - be friendly,
without letting them know specifically what happened. "We had a problem
retrieving your contact list. The admins have been notified. Please try again
in x time" vs "couldn't connect to server... this function failed..."

~~~
NicoJuicy
Handling = continue like nothing happened. So no errors/friendly messages to
the end user.

~~~
lsiunsuex
But you said yourself "I'm a fan of showing the error."

Showing an error and allowing the user to decide what to do is apart of the
handling process, no ?

You can try / catch all day long, but if the app crashes or doesn't produce
the right data - the user must be informed, no ?

~~~
NicoJuicy
Yes, showing a friendly error. Is also showing the error.

The difference was silent fail ( not informed) or not.

Like I said before, where I explained the definition of handling in this
context:

> Handling = continue like nothing happened.

You agree with me in a question, so it seems.

