Why Generic API Error Messages Hurt Users and How to Handle Exceptions Properly

When you see the interface you provided being used by such a service consumer, what would you think?

try {
    // pre‑business logic
    // call DD's interface
    feignClient.execute();
} catch (Exception e) {
    return "DD's interface exception, please follow the public account \"Programmer DD\" and contact the author to handle the exception";
}

As an experienced developer, let’s rationally analyze the problems with this approach:

When calling a third‑party API, many issues can arise that are not the third‑party’s fault, such as network problems that prevent the request from reaching the provider; therefore returning a generic "DD's interface exception" is unreasonable.

The catch block swallows the exception without outputting the stack trace, making it difficult to locate the root cause later and leading to blame‑shifting between parties.

Users do not care who the developer is; error messages should be oriented toward the user, using language they can understand.

Also, as a service provider, you should keep comprehensive request logs for both inbound and outbound traffic to handle future sabotage cases. So, are your interface service logs in place?

Finally, reflect: Do you have teammates who sabotage services? What problems do you see with this handling method, and how would you deal with such service consumers?