maybe this should be id and the request id should be requestId?

Ok why not. Done

I wonder if we should omit the request ID here. I don't think it's useful for anything to the user. Typically in production a user would report the exception ID and then you can search the logs to find other request information.

Ok done

There could be a multiple levels of exceptions (i.e. this cause could have a cause), so this might actually miss the root cause, which could be really confusing to the developer. If we want to provide all information this should probably be a recursive structure.

Done.

Instead of a recursive structure, I chose to use an Array. We can discuss that. If you prefer a recursive structure, I can change the code.

I chose the Array because, IMO, it'll look like a stacktrace we have in a console.

Yeah, I'm not sure what the best thing is here. I'd like to make it clear how to find the "root cause" exception though. Using a list seems strange since it's a chain of causes. What was your motivation for using an array?

I guess it doesn't matter that much in the end, since this is just a dev mode tool. Maybe it would be enough to include the entire recursive stack trace in the initial stackTrace and not list causes at all?

Since this is a dev tool, which should make life easier, then I would favor a format that is easily consumable by developers. Maybe we just need the complete stack trace as a String field? I mean, it looks like it would be easier to read than a recursive structure or a List.

Moreover, we can make it extensible so that users can easily replace the error reporting format if they want/need.

WDYT?

Yeah, I'm fine with having the complete recursive stack trace in the exception message.

(the test should also verify this)

First,

Maybe we just need the complete stack trace as a String field

Yes, I agree.

Do you think that it's possible to use the Logger to format this string ?

IMO, the best default format we can provide to the user is the one he configured. He could already had configured how errors are reported in its Log4j configuration.

For example, the user could have chosen to log with the root cause first thanks to the "%rEx" option of Logback: https://logback.qos.ch/manual/layouts.html#rootException

It could be a good idea to use this configuration.

WDYT ?

Second,

Moreover, we can make it extensible so that users can easily replace the error reporting format if they want/need.

Good idea. It'll be done

After some research, I didn't find any way to use the Logger to format the exception.

You can get the same output as printStackTrace by doing:

val errors = new StringWriter
exception.printStackTrace(new PrintWriter(errors))
errors.toString

Typo: expcetion -> exception

Fixed. Thanks

I think what we were suggesting is to display the full stack trace of the original exception like "stacktrace" -> formatDevServerErrorException(exception), right @marcospereira?

@gmethvin yes, that is right.

But if I undestood the code correctly, it is already doing that. We only need to change from cause to stacktrace.

This code formats exception.cause and I think we want to format exception.

Do we really want to format exception which is a UsefulException ?

Oh I see, the UsefulException is already wrapping the "real" cause exception, which is what we want the stacktrace for.

Exactly. That's why I think it's better to do formatDevServerErrorException(exception.cause) than formatDevServerErrorException(exception).
The UsefulException doesn't provide any useful information in the stacktrace.

But I can change "cause" -> to "stacktrace" -> if you prefer.

Yeah is stacktrace ok with you? Seems more clear.

Wrong Javadoc link, must be {@link ...}

A small detail to solve after rebasing.

Thanks for reviewing, @PromanSEW.

Wrong Javadoc link, must be {@link ...}

Typo: expcetion

Wrong Javadoc link, must be {@link ...}

What do you think about just extending HttpErrorHandler instead and removing these extra methods? You could also factor out the dev/prod logic for onServerError into a helper so all you need here is onClientError and onServerError. It seems like it would be less code and easier to understand. For the API use case you're describing I can't see much value in overriding this. Actually I think it'd be nicer to have fewer things to override, so it's easier to make sure your error format is consistent.

Hi @gmethvin,

I wasn't sure to understand what you want here, so I implemented what I understood in a second PR you'll find here: https://github.com/guizmaii/playframework/pull/1

I'm not sure that you'll like it that much.
It's not very retrocompatibility friendly.

But it's the only way I see to not duplicate the onClientError and onServerError code.

I implemented the same thing as in https://github.com/guizmaii/playframework/pull/1 but in a more OOP way here: https://github.com/guizmaii/playframework/pull/2

It could be more compliant with the way Play is implemented.

Eager to have your feedback on that.

I think that the second solution is nice.

Hmm, that's not exactly what I was suggesting.

JsonHttpErrorHandler#onClientError can simply be:

override def onClientError(request: RequestHeader, statusCode: Int, message: String): Future[Result] = {
  Future.successful(Results.Status(statusCode)(error(Json.obj("requestId" -> request.id, "message" -> message))))
}

The implementation is basically the same for all these helpers (onBadRequest, onForbidden, etc.). For a JSON API I don't see any need to single out these error codes and give them their own methods, so I think we should just extend HttpErrorHandler and implement it once in onClientError.

onServerError is a bit trickier to simplify, but it'd be fine to do something like:

def onServerError(request: RequestHeader, exception: Throwable): Future[Result] = {
  try {
    val usefulException = HttpErrorHandlerExceptions.throwableToUsefulException(
      sourceMapper,
      !config.showDevErrors,
      exception
    )
    logServerError(request, usefulException)
    Future.successful(
      InternalServerError(
        if (config.showDevErrors) {
          devServerErrorJson(request, usefulException)
        } else {
          serverErrorJson(request, usefulException)
        }
      )
    )
  } catch {
    case NonFatal(e) =>
      Logger.error("Error while handling error", e)
      Future.successful(InternalServerError)
  }
}

protected def devServerErrorJson(request: RequestHeader, exception: UsefulException): JsValue = {
  error(Json.obj(
    "id" -> exception.id,
    "requestId" -> request.id,
    "exception" -> Json.obj(
      "title" -> exception.title,
      "description" -> exception.description,
      "stacktrace" -> formatDevServerErrorException(exception.cause)
    )
  ))
}

protected def serverErrorJson(request: RequestHeader, exception: UsefulException): JsValue = {
  error(Json.obj("id" -> exception.id))
}

I was thinking we could do something for the common code for onServerError between the HTML and JSON error handlers, but it's not really that much duplicated code. The more complex we make the implementation, the more we have to worry about backwards compatibility issues now and in the future. These error handlers are just meant to be convenient defaults; we don't have to consider every case for customization.

Also we can avoid adding a useless => Option[Router] dependency if we avoid extending DefaultHttpErrorHandler.

Minor thing, but I wonder if we should remove the "default" in the name (i.e. JsonHttpErrorHandler), since this isn't actually the default.

Agree

getDevErrorJson/getProdErrorJson?

devErrorJson / prodErrorJson, I don't like the get

This is referring to the Java class. I'd assume Scala users would want to use the Scala version of the error handler (especially if they decide to extend it later).

Fixed here: #8641