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.
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
SLF4J Logger rewrite part2 #492
Conversation
Would suggest waiting with merge until next version bump |
May I suggest to take advantage of slf4js methods and instead of separately logging stack traces, append them to the message they belong to? The output should look exactly the same in terms of information content, with the benefit of making life easier on log aggregators which may get confused by the current behaviour of doing two log calls for a single issue (concrete example of when things go wrong: using the logback appender for sentry) Instead do: catch (JSONException ex)
{
LOG.warn("Got an unexpected Json-parse error. Please redirect following message to the devs:\n\t{}\n\t{} -> {}",
ex.getMessage(), type, content, ex);
}
catch (Exception ex)
{
LOG.error("Got an unexpected error. Please redirect following message to the devs:\n\t{} -> {}", type, content, ex);
} |
The only issue is that if you use the |
And that (together with the fact that i want the json data seperated) is why i did it the way i did |
That's not true. |
What are the benefits of doing that? There is no information lost by attaching the stacktrace to the source of it. |
|
@@ -514,7 +515,7 @@ else if (sample < Short.MIN_VALUE) | |||
} | |||
catch (Exception e) | |||
{ | |||
LOG.fatal(e); | |||
LOG.error("Something happened!", e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make the comments in this file a bit more descriptive like "Unexpected Exception occurred while X"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:) Yea i didn't know what exactly happened there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its funny how you didn't mention the other 2 exceptions above :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used the plural "comments" for a reason 👀
@@ -313,6 +313,7 @@ public Role getPublicRole() | |||
} | |||
|
|||
@Override | |||
@Deprecated | |||
public TextChannel getPublicChannel() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is going to be in 3.4 we will be removing this method anyway FYI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just added it because gradle build complained about implementing a deprecated method
+ "\nRoute: " + bucket.getRoute() | ||
+ "\nHeaders: " + headers); | ||
Requester.LOG.debug("Encountered issue with headers when updating a bucket\nRoute: {}\nHeaders: {}", | ||
bucket.getRoute(), headers); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok if i remove the isDebugEnabled part?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, doubt that check is needed.
… some logs into a single log statement
@@ -938,7 +938,7 @@ protected void handleEvent(JSONObject raw) | |||
// } | |||
|
|||
JSONObject content = raw.getJSONObject("d"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe move this into the try catch block below? I just got a JSONException on 286 from this line, missing a print of the faulty JSON.
[2017-10-18 12:30:31,889] [ DEBUG] [JDA RateLimit-Queue Pool - Thread 2] n.d.jda.core.requests.Requester: Received response with following cf-rays: [3afad2a07e74646f-FRA]
[2017-10-18 12:30:47,770] [ ERROR] [JDA [1 / 2] MainWS-ReadThread] n.d.j.core.requests.WebSocketClient: Encountered an Exception
org.json.JSONException: JSONObject["d"] is not a JSONObject.
at org.json.JSONObject.getJSONObject(JSONObject.java:641)
at net.dv8tion.jda.core.requests.WebSocketClient.handleEvent(WebSocketClient.java:947)
at net.dv8tion.jda.core.requests.WebSocketClient.onTextMessage(WebSocketClient.java:666)
at com.neovisionaries.ws.client.ListenerManager.callOnTextMessage(ListenerManager.java:352)
at com.neovisionaries.ws.client.ReadingThread.callOnTextMessage(ReadingThread.java:260)
at com.neovisionaries.ws.client.ReadingThread.callOnTextMessage(ReadingThread.java:238)
at com.neovisionaries.ws.client.ReadingThread.handleTextFrame(ReadingThread.java:963)
at com.neovisionaries.ws.client.ReadingThread.handleFrame(ReadingThread.java:746)
at com.neovisionaries.ws.client.ReadingThread.main(ReadingThread.java:108)
at com.neovisionaries.ws.client.ReadingThread.runMain(ReadingThread.java:64)
at com.neovisionaries.ws.client.WebSocketThread.run(WebSocketThread.java:45)
[2017-10-18 12:31:21,579] [ DEBUG] [fredboat.FredBoat.main()] n.d.jda.core.requests.Requester: Received response with following cf-rays: [3afad3d719096361-FRA]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is the right PR to do that in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seing as this is already fixed in another pr, not gonna implement here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That cannot be moved into the try/catch block because the json is used within the catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aight. My intent on suggesting that was less concerned with the current bug, more of a general idea to improve future logging.
And Minn is correct, the change is more complicated than moving the two lines into the try catch, I'm sure whoever decides to add this in here or in another PR will figure out something appropriate. Maybe look at other similar places for possible uncaught JSONExceptions and have PR for that after this is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than those two minor thing this pr looks good to me, too.
@@ -18,7 +18,7 @@ | |||
* Package which contains all utilities for the JDA library. | |||
* These are used by JDA itself and can also be useful for the library consumer! | |||
* | |||
* <p>This contains the JDA logger implementation {@link net.dv8tion.jda.core.utils.SimpleLog SimpleLog} | |||
* <p>This contains the JDA-specific Logger factory {@link net.dv8tion.jda.core.utils.JDALogger JDALogger} | |||
* <br>Which is currently planned to be rewritten to be more end-user friendly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the rewrite isn't planned but finished.
String getString() throws Exception; | ||
} | ||
|
||
private JDALogger() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the inner class be at the end of the file?
…rror occurs outside of handling Applied review suggestions
Completely removed SimpleLog in favor of a SLF4J Logger.
{}
JDALogger#getLazyString(LAMBDATERM)
to lazily construct String from expression as slf4j doesn't support that natively yet