Jda: Event for when JDA encounters an exception

[Scarsz]

Take errors such as below and turn it into an event so we can deal with it as we'd like instead of it forcibly being pushed to the console as stack traces tend to scare people who don't know what they are/shouldn't need to be concerned with them.

[Mon, 3. Apr 2017 19:47:32 ERROR] [JDA] Encountered an exception:
[Mon, 3. Apr 2017 19:47:32 ERROR] [JDA] com.mashape.unirest.http.exceptions.UnirestException: java.net.SocketException: Connection reset
    at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:143)
    at com.mashape.unirest.request.BaseRequest.asString(BaseRequest.java:56)
    at github.scarsz.discordsrv.dependancies.jda.core.requests.Requester.execute(Requester.java:122)
    at github.scarsz.discordsrv.dependancies.jda.core.requests.ratelimit.BotRateLimiter$Bucket.run(BotRateLimiter.java:301)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at sun.security.ssl.InputRecord.readFully(Unknown Source)
    at sun.security.ssl.InputRecord.read(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
    at sun.security.ssl.AppInputStream.read(Unknown Source)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
    at github.scarsz.discordsrv.dependancies.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
    at github.scarsz.discordsrv.dependancies.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
    at github.scarsz.discordsrv.dependancies.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
    at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:138)
    ... 10 more
[Mon, 3. Apr 2017 19:47:32 ERROR] [JDA] RestAction queue returned failure: [ErrorResponseException] Discord returned an error with no defined error-code : null

[Almighty-Alpaca]

Something like that has already been brought up lately. It was supposed to also catch errors thrown by EventListeners, but there's one problem: When an EventListener that listens for the ErrorEvent throws an exception JDA would get stuck in an infinite loop

[Scarsz]

Wouldn't a simple solution to that be to just not report errors that an ErrorEvent listener throws? Add that into the javadoc in bold: "can't be done for obvious reasons." The listener should only be listening to exceptions within JDA anyway, I would attest that exceptions in ErrorEvent listeners shouldn't be included in that.

[SparklingComet]

Sure it would be a simple solution, but remember that you can use try-catch blocks which are already part of the Java language.
I understand that putting every single event in a try-catch block might not be as efficient, however "muting" exceptions is an even worse idea.

[DV8FromTheWorld]

That...that isn't what he is talking about @ShanerX. He is referring to the exceptions printed from within JDA. He is hoping to have the stack trace stuff removed and replaced by their simple message and forwarded to an ExceptionEvent.

[SparklingComet]

I beg your pardon, maybe I didn't understand the topic.
Again, shouldn't this be do-able with a try-catch block?
Also, @Scarsz said that (quoting):

deal with it as we'd like instead of it forcibly being pushed to the console as stack traces tend to scare people who don't know what they are

Silencing exceptions so the user doesn't see them isn't recommended, especially on a production bot.

[MinnDevelopment]

This an exception that is thrown by the JDA Requester and then logged and sent to the failure callback of a RestAction.

[Scarsz]

@ShanerX no, it's not try-catchable. The exceptions are thrown completely internal to JDA, there's no spot where a user's code could catch anything. Also, silencing the exceptions was not the intention. As I said in the OP, getting rid of stack traces is the intention. End users that don't know what they are get frightened from seeing them. Id prefer to be able to handle the exceptions and display a message myself.

[serebit]

I can see situations where this would be useful.

[Scarsz]

Having an ErrorHandler interface might be an effective implementation for this. JDABuilder::setErrorHandler, have the default/unspecified behavior be to an implementation that reflects JDA's current behavior.

[DV8FromTheWorld]

@Scarsz that is a good idea, use the same mentality as Thread.setDefaultExceptionHandler
However, that is pretty much the same thing that onException would provide, except that you'd be able to register multiple handlers for it

[Scarsz]

I hear you on it, I just can't think of any situations where a bunch of error handlers would be better than one central one besides just having the option for it

[MinnDevelopment]

Exceptions and errors that are caught by JDA internals are passed into respective sections of the API. This means you can handle them through the ExceptionEvent or for RestAction with the failure callbacks. The logging of timeouts and requester errors is intentional behavior and I don't want to change it since it seems unnecessary and misleading. Timeouts and HTTP issues should be at a minimum for proper functioning communication anyway, if an issue rises it should most certainly be logged including the stacktrace for better issue prevention. JDA attempts to retry on an HTTP timeout once if it occurs, if that retry fails as well we will print the timeout exception to alert the end user of the faulty connection.
Since JDA makes use of the SLF4J api it is possible to configure the logger to ignore or filter out any exception, although I highly discourage from ignoring them.

My mentioned concerns and the fact this issue has been stale for such a long time are reason enough to close the thread.