Open artem-zinnatullin opened 9 years ago
One problem is that URLs occasionally contain sensitive data in them, and exceptions get posted to relatively insecure bug trackers.
That's why it's a flag which you can enable only for internal/debug builds!
On Sun, Oct 4, 2015, 01:08 Jesse Wilson notifications@github.com wrote:
One problem is that URLs occasionally contain sensitive data in them, and exceptions get posted to relatively insecure bug trackers.
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-145294007.
@artem_zin
This seems fairly low-leverage for a setting. We try and prefer sane defaults that work for most than exposing every possible configuration. I'd rather pick something that can always be used.
On Sat, Oct 3, 2015, 7:08 PM Artem Zinnatullin notifications@github.com wrote:
That's why it's a flag which you can enable only for internal/debug builds!
On Sun, Oct 4, 2015, 01:08 Jesse Wilson notifications@github.com wrote:
One problem is that URLs occasionally contain sensitive data in them, and exceptions get posted to relatively insecure bug trackers.
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-145294007.
@artem_zin
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-145296584.
I'd rather pick something that can always be used.
I've thought about this a lot, but I just don't know how to include URL (since it's most valuable info for the REST client) into the exception and don't leak any sensitive info… So I came to the flag that could be enabled/disabled for particular types of builds and will be disabled by default.
Moreover, I would like to use this option to include URL and response body to the exception in case of response parsing fail (imagine unexpected/incorrect JSON/etc) to make debugging and error fixing extra easy task with Retrofit!
Picasso has same setting (setIndicatorsEnabled()
) and everybody loves it!
Would just the static information pulled from the method be suitable? You won't get information like path/query values or headers, but it should be enough.
Picasso has same setting (setIndicatorsEnabled()) and everybody loves it!
That is a vastly different setting than anything proposed in this issue.
Would just the static information pulled from the method be suitable?
Hope you mean method of user created interface used for retrofit.create()
and not the HTTP method? If so — it would be nice to see something like ... problem occurred during execution of GitHubService.contributors()
!
That and the relative path template, HTTP method, etc.
LGTM, I'll work on it if you don't mind.
On Fri, Oct 9, 2015, 5:26 PM Jake Wharton notifications@github.com wrote:
That and the relative path template, HTTP method, etc.
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-146886452.
@artem_zin
Please do!
On Fri, Oct 9, 2015 at 11:21 AM Artem Zinnatullin notifications@github.com wrote:
LGTM, I'll work on it if you don't mind.
On Fri, Oct 9, 2015, 5:26 PM Jake Wharton notifications@github.com wrote:
That and the relative path template, HTTP method, etc.
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-146886452.
@artem_zin
— Reply to this email directly or view it on GitHub https://github.com/square/retrofit/issues/1162#issuecomment-146901715.
Hi guys, how about using okhttp interceptors for logging. If you use dagger you can easily inject a Retrofit instance with logging interceptor when needed (i.e. debug mode). If you don't need logging you can inject Retrofit without It. Have a look at this https://stackoverflow.com/questions/32514410/logging-with-retrofit-2
What do you think about a flag for including debug info (such as
request.toString()
) into exceptions?Usage:
Example of a stacktrace of incorrect call via RxJava without debug info:
Example of a stacktrace of incorrect call via RxJava with included debug info:
Async request (RxJava, etc) loses information about its start point (jumps to the other Thread and booms there), stacktraces become useless :crying_cat_face:.
Logging is a great helper too! But sometimes you just don't want to log all the requests to keep the log readable, but you also want to see as much info as possible about the problems. Once I've spent several hours on trying to fix a request that was correct but because of a massive amount of async requests in the app — the last thing before the crash that I saw was a log of this correct request when the actual problem was in a request that fired few seconds before this.
At the moment, I have a draft of this feature where I add
request.toString()
to the exception message. And it works even if you fail before the request execution (converters/calladapters detection problems), also we can include more info in case of response parsing fail.