finagle / finagle/featherbed

Better InvalidResponse / ErrorResponse messages?

Open
#68 2 comments 2 reactions 0 assignees View on GitHub
Dominant language
Scala
Stars
138
Forks
25
PR merge metrics
No merged PRs in 30d

Description

In a complicated API, even when handling errors explicitly, there are times when you still get a stacktrace like the one below, which doesn't help you find the error (especially in complicated workflows where the exact call that failed is hard to determine):
```
featherbed.request.ErrorResponse: Error response received
at featherbed.request.RequestTypes$RequestSyntax$$anonfun$featherbed$request$RequestTypes$RequestSyntax$$handleRequest$1.apply(RequestSyntax.scala:123)
at featherbed.request.RequestTypes$RequestSyntax$$anonfun$featherbed$request$RequestTypes$RequestSyntax$$handleRequest$1.apply(RequestSyntax.scala:84)
at com.twitter.util.Future$$anonfun$flatMap$1.apply(Future.scala:1089)
at com.twitter.util.Future$$anonfun$flatMap$1.apply(Future.scala:1088)
at com.twitter.util.Promise$Transformer.liftedTree1$1(Promise.scala:107)
...
```
At least InvalidResponse includes the reason in the message, but ErrorResponse is a complete black box if it gets thrown in a place you didn't explicitly handle it.

I'm wondering if some information from the Request and/or Response might be helpful in constructing the message ([here](https://github.com/finagle/featherbed/blob/master/featherbed-core/src/main/scala/featherbed/request/RequestSyntax.scala#L21-L31)), or if you have other suggestions on how this might be made easier (without wrapping all code in try-catches).

I'm happy to help with implementation, but wanted to see if there was a better way to handle this before I dove in.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.