-
Notifications
You must be signed in to change notification settings - Fork 338
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
Exceptions on callbacks are always logged to stderr #518
Comments
@mateusduboli Hi Mateus! Have you considered wrapping your callback function to catch + handle exceptions in your preferred way? If that's for some reason not possible or desirable, could you please explain why so that I can better understand your situation? Thanks! |
|
In my specific case the callback function is managed by another library,
namely martian
https://github.com/oliyh/martian
There are options to resolve it, like not using exceptions as a control
flow, however it still feel that the library does not provide enough
flexibility to for instance send these exceptions to a file.
…On Thu, 20 Apr 2023 at 05:09 Shantanu Kumar ***@***.***> wrote:
A proposed solution, would be to use the ContextLogger from the client
<https://github.com/http-kit/http-kit/blob/v2.6.0/src/org/httpkit/client.clj#L243>
variable calculated just before the call.
But Ideally these logs should comply with slf4j or some other interface
that would allow for more fine grained control using configuration files.
ContextLogger is an interface, so you can log to anything in the
implementation. This eliminates 3rd party dependency.
—
Reply to this email directly, view it on GitHub
<#518 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4FOKKDZQG2LX5WGCQXKDXCDVNBANCNFSM6AAAAAAXEU46PQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Could you please expand on this? Where are exceptions being used as control flow?
By "the library", do you mean http-kit or Martian? If http-kit: is there some other place (besides the client request callback) where you want to control the behaviour on errors and cannot? |
This is being used in my application, where when the status code is above 400 it will wrap the response in an exception, this exception is used on my "handler" code to perform decisions. (require '[org.httpkit.client :as http])
(defn process-response [{status :status :as response}]
(if (>= status 400)
(throw (ex-info "Error in response" {:response response}))
response))
@(http/request {:method :get
:url "http://httpstat.us/400"}
process-response) This code both returns the exception and prints it on (defn safe-process-response [response]
(try
(process-response response)
(catch Throwable t
(log-and-suppress-error t)) The problem is, IF I don't have access to the code that manages these callbacks, I cannot suppress the exception going to the
I mean
I think any place that uses a hardcoded reference to https://github.com/search?q=repo%3Ahttp-kit/http-kit%20printError&type=code |
From what I can see there, http-kit appears to only use I.e. the design appears to be that these That seems generally reasonable to me, given that custom error handling is fundamentally a superset of custom error logging. Though I understand that in your case, the library you're using seems to be obscuring access to custom error handling. Assuming there's no way of providing a custom handler in Martian, it seems the options are:
The two aren't mutually exclusive, and both could be independently worthwhile. Cheers :-) |
Studying the code I wanted to double check some understandings that I have about org.httpkit.client/request and its relation to HttpClient.
What I'm trying to organize is the relation between the However, because they are executed in different thread-pools and in contexts which the From that, it seems the simplest solution would be to add a Do you see any other ideas? |
Hi Folks!
HttpKit Version:
v2.6.0
When there is an exception on the
callback
function fromhttp/request
the exception will always be printed using HttpUtil/printError.This is undesirable as there is no way to control over this information and make it difficult to monitor for problems when there are expected exceptions.
A proposed solution, would be to use the
ContextLogger
from the client variable calculated just before the call.But Ideally these logs should comply with
slf4j
or some other interface that would allow for more fine grained control using configuration files.The text was updated successfully, but these errors were encountered: