Skip to content

fixing error message in a log statement #13791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TZubiri wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fixing error message in a log statement #13791

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion ...-clients/src/main/java/org/wso2/am/admin/clients/registry/ResourceAdminServiceClient.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,7 +221,7 @@ public String getMimeTypeFromHuman(String mediaType) throws Exception {
try {
return resourceAdminServiceStub.getMimeTypeFromHuman(mediaType);
} catch (Exception e) {
String msg = "get human readable media type error ";
String msg = "get mime type from human error ";
Copy link

Copilot AI Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message is still unclear/grammatically awkward and ends with a trailing space. Consider a clearer, actionable message and include context, e.g., String msg = "Error getting MIME type from human-readable media type for: " + mediaType; (remove trailing space and improve capitalization).

Suggested change
String msg = "get mime type from human error ";
String msg = "Error getting MIME type from human-readable media type for: " + mediaType;

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Author

@TZubiri TZubiri Oct 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't quite matter or is highly secondary.

In situations where only the error message is logged, and not the exception stack, the error message serves more as an error ID than a useful descriptor, the logging debugging workflow will be grepping the exact error message through the codebases to find the exact codepath.

Logging the actual exception stack as-is might be a reasonable suggestion (with the counterargument that it might pollute log files), but is somewhat beyond the scope of this bug, which is that the bug id/msg is a duplicate, and thus code execution information is lost on logs.

Copy link
Copy Markdown
Author

@TZubiri TZubiri Oct 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally the + mediaType introduces the possibility of type errors, which would risk an exception during exception error, making this suggestion hugely net negative.

We should think of code in a catch block as a second serve in tennis, slow and careful instead of featureful and optimistic

throw new Exception(msg, e);

}
Comment on lines 221 to 227
Copy link

Copilot AI Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Catching Exception and rethrowing a new generic Exception obscures the original, more specific exception type and adds little value. Prefer either: (a) remove the try/catch and let the stub's exception propagate, or (b) rethrow the original exception (throw e;) to preserve type, or (c) wrap in a more specific checked exception used by this client rather than java.lang.Exception.

Copilot uses AI. Check for mistakes.
Expand Down