1

Assuming you have a software which you gave to clients.

Now we all know that exceptions can be saved to files, databases, and so on for tracing errors by technicians. As all engineers know, no Apps in first releases will be bug-less, but it must have bugs for either logical or randomly unknown reasons, such as [Hard disk is full] and client try to Export PDF file, or save things to DB.

There's points, which i need to know from seniors :

  1. what really should we do to catch all kind of exceptions without showing any error messages to clients? Is There any OpenAPI or Exception Email-Friendly API for that?

  2. Is it good to show exception messages, or just Red Flag, or some Color that when the client sees, they would contact technicians?

Thats All !

  • This question is asked as if you were never be a user of an application by yourself. Which piece of software would you buy - one which does not tell you it cannot export a certain file because the hard disk is full, or one which tells you exactly this? – Doc Brown Nov 5 '19 at 21:27
  • Is this question for a web app, a device/phone app, or for a desktop app? I think that affects the answer. – John Wu Nov 6 '19 at 1:53
8

Not showing the user any errors is a fantasy requirement. Only showing users errors they can do something about is far better. Don't show "error 4". You can do better.

Halting the system when it's going into an undefined state is a good thing. Undefined systems can mangle the database, format the hard drive, and send the president threatening emails. If you can't tell what will happen next roll over and die.

But remember that the user is a mere human who hasn't read any of your code. Politely tell them whats going on, why they're losing their work, and what they should do about it if you can do it safely.

If you backed up their work tell them you're attempting to restore it. This way they can check if you really did.

If you have complicated debugging info you want them to share with you make doing that as simple as possible without turning your product into spyware.

Above all, remember that your users are not you. What you think is easy is not important. Find out who they are and what they can deal with.

| improve this answer | |
  • 2
    The one thing I would add to this answer is to spend a little bit of money and time on a tool to record exceptions like Sentry, Rollbar, Airbrake, etc. The analytics these provide help you quickly find common exceptions so that they can be easily and quickly addressed. – Jeff Siver Nov 6 '19 at 5:17
  • Jeff. thanks you. i really was forbid the Monitoring tools or i don't know its exists. i think we will write one from scratch. – CowBoy Nov 7 '19 at 4:06
5

When discussing error handling, you need to determine what your real requirements are. There's a progression of error handling that you should work towards:

  1. You are able to recover from the error automatically and use alternative processing to satisfy the user's request.
  2. All error notifications that make it to the user are clear and the user knows what they need to do to fix the problem.
  3. Unanticipated error prevents the user's request from being fulfilled, but the error is logged and the application moves on.
  4. Unanticipated error causes the application to be in an invalid state, so it must shut down. (typically only affects command line or desktop applications).

The bottom line is that you give the user enough information so they know what to do. Stack Traces are not nice user experiences, but they are invaluable to developers to figure out what might be happening. As a result, you want to hide the stack trace from the user when you can. In the first two cases, the user would never see a stack trace.

In the third case, I've seen multiple solutions for it. One option is to provide feedback to the user with the message associated with the exception, and an error identifier that matches a line in the logs. That makes searching logs really easy. I've also seen systems that send an email to a development distribution group or a Jira instance to create/update a ticket from that error message. I've also seen systems that allow the user to expand a textbox that has the stack trace so they can copy and paste it in an email when they make their trouble report.

It's not a pleasant experience to have a message that contains the stacktrace, however it's better than nothing at all. You need to determine how you expect the user to deal with the situation, and how you expect them to provide the debugging information to your team if needed.

If you can, automate the process of making a bug report. If not (and there are plenty of reasons why it's not possible), you have to decide how the information gets to you--or if this is free software and you provide no active support, you need to make that abundantly clear. At least provide a guide so that users can find and figure out the problem for themselves.

| improve this answer | |
1

There is an assumption in your question that is wrong. Hiding errors from users is not helping anyone.

You may want to generalize the message presented to the user but it should be clear something went wrong and what that means to the state of the application. Just pretending nothing happened is bad because there will obviously be some impact on the behavior of the application (or you would not have to throw). And you do not want the user to deal with unexpected behavior, to make him think everything is fine while it is not. Like make him believe his work was saved alright while it was not.

So there is no best way. We could speculate about a worst way but that would not be very productive.

| improve this answer | |
1

... what really should we do to catch all kind of exceptions without showing any error messages to clients?

Never showing users an error suggests that the Application is perfect, the Operating System never hangs, the Network never glitches and there's never an 'R' in the month. It's simply not possible. Applications can crash and burn so spectacularly that you can't even catch the Exception that's thrown, even if you wanted to.
Forget about "never".

Is There any OpenAPI or Exception Email-Friendly API for that?

Short answer: No.
It may be that your program gets into such a bad state that it can't run any of that code anyway (trying to run yet more code in response to an OutOfMemoryException probably isn't going to work too well).

Is it good to show exception messages ...

Provided that message is meaningful to the User and, preferably, gives them some clue about how to "fix" (or "handle") the problem, then yes.

Complete Exceptions (message, stack trace and all that) are downright painful to look at, even if you're a professional.

A User will simply see a wall of meaningless words, click "OK" to kill the application and then start it straight back up again. Whatever they were trying to do is "important". Getting the details of that Exception back to your Developers is not.

This is why you should never rely on users to tell you what went wrong with the application - they don't know and, to be blunt, they don't care.

... or just Red Flag, or some Color that when the client sees, they would contact technicians?

"Flags" and "Colors" suggest that things are happening within the application that you are handling correctly and these things are preventing the user from doing what they want to do. This is exactly what your should be doing - handling Exceptions so that the program doesn't die, and giving the user meaningful feedback, telling them whatever they just tried didn't work. How you do that is less to do with Exception Handling and more to do with User Interface design, with the former feeding into the latter.

| improve this answer | |
0

Direct answers

what really should we do to catch all kind of exceptions without showing any error messages to clients?

The best way to enforce this is to catch exception top-level (e.g. in the api controllers). My experience is with ASP.Net, which gives you clean ways of doing so, e.g. the HandleError attribute.

Is There any OpenAPI or Exception Email-Friendly API for that?

I am unsure of other existing solutions as I'm strictly a .Net developer. I would assume similar solutions exist for other frameworks. If not, then you can still develop one yourself. The main focus is to catch it top-level to ensure that all of your application's exceptions are caught. Ideally, you'd want a blanket solution that automatically covers the entire API.

Is it good to show exception messages, or just Red Flag, or some Color that when the client sees, they would contact technicians?

I will elaborate more on this below. In short: curated willful exceptions (i.e. explicitly written by your developer with the intent to communicate something to the end user) can be shown, unexpected exceptions (i.e. not explicitly written by your developer) or intentionally private exceptions (i.e. written by your developers but not with the intent to communicate with the user) should not be shown.

In all cases, exception details other than the message should always be hidden from end users. At most, you can show it e.g. only if the current authenticated user is an admin of the system, assuming that the admins are people who are trusted with the exception details.

In absence of an allowed error message to show, you should still clearly communicate to the end user that an error has occurred. You'd also want to log the real exception somewhere in the backend so that a developer is able to figure out what exactly went wrong.

Never hide an exception and then also not log it. This is the equivalent of a swallowed exception and is an obstacle to proper debugging.

Assuming you have a software which you gave to clients.

This is an interesting point.

If the customer is running the application on their own server, then you should not obfuscate the errors, as the customer would be wholly unable to debug any issue with the application they bought.
I (cynically) assume you can get away with doing so legally, and it might be an efficient way to ensure they come to you for support, but I disagree with this approach on an ethical level.

If the user bought your software and runs it on their own hardware, they deserve to know how the software works and exactly what went wrong.

Besides, if the customer has access to the application files, they are already able to figure out anything about the application that an exception would reveal. This is different from e.g. a web service, as the end users do not have access to the application files and therefore cannot reverse engineer them.


In more detail

Pretty much any discussion on the exposure of exceptions (naturally occuring ones or intentionally thrown ones) ends up as a debate on opinions. Different people expect different behaviors and thus find different approaches acceptable.

I'm not going to focus on the subjective, as we won't find a consensus. However, I will give you a collection of tips on how to handle the (non-)exposure of exceptions to the end user in a way that maximizes utility (UX, debugging) while still avoiding security leaks.

Do not expose exceptions to the end user

You're already aware of this, but I'm reiterating the point. Leaking naked exceptions reveals information about your application (e.g. if you're using a particular library, or method names that suggest particular implementations).

Do expose user-friendly messages

User's don't like errors that don't make sense to them. Did they do something wrong? Did the server do something wrong? They are left at a loss.

Even a vague message is better than no message at all, but of course a message that is not vague (within reason) is even better.

Willful exceptions versus unexpected exceptions

In past projects, I have taken the following approach in order to handle error logic sensibly (in my opinion). The main point here is that there are some exceptions where you do want to reveal it to the user (at least the message), e.g. when a validation fails, and this approach allows for that while still preventing unwanted messages from leaking.

When a willful exception was thrown (e.g. due to a validation error), we always used a PublicException (our own class, nothing more than a PublicException : Exception {}) or any exception that derives from PublicException. We then handled any exception at the top level (the api controller) and separated them based on type:

  • In DEBUG mode (#if DEBUG), full exceptions (.ToString()) were returned because debug mode is only to be used by developers. This is dangerous if you run the risk of ever deploying a debug version on production but due to our build pipeline we weren't particularly afraid of this happening.
  • If it's a PublicException, return the exception message as part of the response
  • If it's not a PublicException, return "An error has occurred" as the response message

This gave developers the ability to raise an exception which they specifically intended to carry a message to the end user.
However, any exceptions that were not foreseen by the developers (random failures, unexpected runtime errors, ...) would not be shown to the end user as this message was not verified by a developer.

This worked well. However, there is a "don't flow-by-exception" argument here. I'm a big fan of prohibiting flow-by-exception in general, but that is not synonymous with never raising exceptions in the first place.
When you use this PublicException approach, developers may become sloppy and start wantonly using exceptions for program flow, and you need to actively check up on the code quality to ensure that this doesn't happen. But to be honest, you would always need to be checking for antipatterns even if you weren't using the PublicException approach.

Store the exceptions in a developer-accessible way

Extending the previous tip, when we handled unexpected exceptions that would be hidden from the end user, what we did was log this exception to the error log using a unique ID (GUID in our case), and we then added the UID to the error message. The user would get something like:

An unexpected error has occurred for your request. If this problem persists, please contact the {COMPANY} helpdesk and reference your error ID ({GUID})

This achieves the best of both worlds. The issues with giving the end user the full exception are already clear. But if you just log the exception, then it becomes hard for a developer to figure out which exception in the error log belongs to which user (unless you have perfect logging, which in reality you often don't).

By giving the user a direct reference to the exception, you've basically given them the ability to tell the developer exactly what went wrong (= exception details) but you've hidden the information from the user themselves (= they only know a meaningless GUID number).

| improve this answer | |
  • Exceptions are there to make the app work. UX design decides what to tell the user in which situation. They shouldn’t be confused. – gnasher729 Nov 6 '19 at 10:09
  • @gnasher729: Selectively passing specific vetted exception messages to the user is a valid UX decision. Exceptions by their very nature entail describing what went wrong to someone. That may not always be the end user, but there are cases where the end user should be clued in. For example, I want my browser to tell me that there is no internet connection and my browser did not encounter an internal error itself, I don't want "an error occured - go fish!" with no clue as to whether it's an issue in the browser's runtime or an external dependency (in this case the internet connection). – Flater Nov 6 '19 at 10:12
  • @gnasher729: Also note that in OP's example it's about an application that was given to the customer. The approach for a web service is different than for an application that a customer runs locally on their own hardware. In the latter case, the machine's administrator needs reasonable error messages to reveal the source of an issue (at the very least distinguishing internal issues from external ones) because otherwise the application is a nightmare to work with. – Flater Nov 6 '19 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.