Quantcast

Custom Error Pages

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Custom Error Pages

Dustin Whitney
Hey guys,

How have you been handling custom error pages?  I can get it working easily from the context I setup to serve static content, but I'm not sure how to make it work in the context where my filters are running.  Any examples?

Thanks,
Dustin
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

soft_props
This sounds like an area for exploration.

Typically I've been using QParams for validation then return a formatted message in a template or a json representation of the list of errors.

I think you are talking about runtime exceptions though. I wonder if it would make sense to intercept uncaught exceptions provide a callback interface on plans (or the server) that would return a function Throwable => Option[HttpResponse => HttpResponse] which by default would return None if you want to ignore exception handling.

Http(8080).filter(Planify({
  case Path("/badcode") =>
}) onError { err => // in scope of the plan
   Some(Html(/*format the error*/))
}))


Http(8080).context("/a") {
  _.filter(Planify({
    case Path("/badcode") =>
  }))
}.context("/b") {
  _.filter(Planify({
    case Path("/morebadcode") =>
  }))
}. onError { err => // in global server scope
   Some(Html(/*format the error*/))
}


I guess in some cases it might make more sense for an http server to say on(StatusCode, fn) or even as an argument to pattern match against do you can return a more semantic response

code match {
  case 500 => Some(...)
  case 404 => Some(...)
  case _ => None
}


The floor is open on this one I think. Any thoughts?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

n8han
Administrator
Dustin, are you talking about configuring the standard Jetty error response pages?

Nathan

On 01/25/2011 09:58 AM, soft_props [via Databinder] wrote:
This sounds like an area for exploration.

Typically I've been using QParams for validation then return a formatted message in a template or a json representation of the list of errors.

I think you are talking about runtime exceptions though. I wonder if it would make sense to intercept uncaught exceptions provide a callback interface on plans (or the server) that would return a function Throwable => Option[HttpResponse => HttpResponse] which by default would return None if you want to ignore exception handling.

Http(8080).filter(Planify({
  case Path("/badcode") =>
}) onError { err => // in scope of the plan
   Some(Html(/*format the error*/))
}))


Http(8080).context("/a") {
  _.filter(Planify({
    case Path("/badcode") =>
  }))
}.context("/b") {
  _.filter(Planify({
    case Path("/morebadcode") =>
  }))
}. onError { err => // in global server scope
   Some(Html(/*format the error*/))
}


I guess in some cases it might make more sense for an http server to say on(StatusCode, fn) or even as an argument to pattern match against do you can return a more semantic response

code match {
  case 500 => Some(...)
  case 404 => Some(...)
  case _ => None
}


The floor is open on this one I think. Any thoughts?




If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/Custom-Error-Pages-tp5958154p5959086.html
To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

Dustin Whitney
Yes, that's what I was talking about, although Doug's idea sounds pretty cool.  Have you got the standard jetty pages working?  Want to share some code?

Dustin

On Tue, Jan 25, 2011 at 10:19 PM, n8han [via Databinder] <[hidden email]> wrote:
Dustin, are you talking about configuring the standard Jetty error response pages?

Nathan


On 01/25/2011 09:58 AM, soft_props [via Databinder] wrote:
This sounds like an area for exploration.

Typically I've been using QParams for validation then return a formatted message in a template or a json representation of the list of errors.

I think you are talking about runtime exceptions though. I wonder if it would make sense to intercept uncaught exceptions provide a callback interface on plans (or the server) that would return a function Throwable => Option[HttpResponse => HttpResponse] which by default would return None if you want to ignore exception handling.

Http(8080).filter(Planify({
  case Path("/badcode") =>
}) onError { err => // in scope of the plan
   Some(Html(/*format the error*/))
}))


Http(8080).context("/a") {
  _.filter(Planify({
    case Path("/badcode") =>
  }))
}.context("/b") {
  _.filter(Planify({
    case Path("/morebadcode") =>
  }))
}. onError { err => // in global server scope
   Some(Html(/*format the error*/))
}


I guess in some cases it might make more sense for an http server to say on(StatusCode, fn) or even as an argument to pattern match against do you can return a more semantic response

code match {
  case 500 => Some(...)
  case 404 => Some(...)
  case _ => None
}


The floor is open on this one I think. Any thoughts?




If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/Custom-Error-Pages-tp5958154p5959086.html
To start a new topic under Unfiltered, email [hidden email]
here.




If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/Custom-Error-Pages-tp5958154p5960528.html
To start a new topic under Unfiltered, email [hidden email]
To unsubscribe from Unfiltered, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

andrewoma
In reply to this post by n8han
Hi,

Is there any progress on this?

I was just about to ask on the list for the idiomatic way of handling runtime exceptions when I noticed this thread. In particular, my issue relates to the following Scalate usage:

val server = Http(8080).filter(unfiltered.filter.Planify {
      case req => Ok ~> Scalate(req, "hello.ssp")
    }).run

If an exception is thrown due to a bad template, you actually end up with a status of OK (200) and a blank body. Ideally, you'd want to trap the exception, return a InternalServerError (500) and perhaps a custom message for debugging.

The proposed error handler certainly looks like a good fit for this. In the mean time is there an elegant alternative? (All I can think of is wrapping the plan/intent and trapping the exception).

Cheers,
Andrew
max
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

max
I generally do something like the below. ErroHandler is an abstract
base class from which I've derived all of my app's plans. If something
bad happens, the exception is caught and some actions are taken. Among
other things, a 500 response is returned, an error SSP template is
rendered (which for administrative users shows an exception, for
others a polite message), and e-mail is sent to the ops team.

abstract class ErrorHandler extends Plan {
  override def complete(intent: Plan.Intent): Plan.Intent = {
    case req @ Path(path) => {
      try { super.complete(intent)(req) }
      catch {
        case t => {
          log.error(t, "[%s]: uncaught exception: %s: %s", path,
t.getClass.getName, t.getMessage)
          CallTheWhaaaaaambulance(req, t)
          InternalServerError ~> HtmlContent ~> Scalate(
            req,
            Some("/lib/error.ssp"),
            Map("exception" -> t)
          )
        }
      }
    }
  }
}


On Wed, Feb 16, 2011 at 22:30, andrewoma [via Databinder]
<[hidden email]> wrote:

> Hi,
>
> Is there any progress on this?
>
> I was just about to ask on the list for the idiomatic way of handling
> runtime exceptions when I noticed this thread. In particular, my issue
> relates to the following Scalate usage:
>
> val server = Http(8080).filter(unfiltered.filter.Planify {
>       case req => Ok ~> Scalate(req, "hello.ssp")
>     }).run
>
> If an exception is thrown due to a bad template, you actually end up with a
> status of OK (200) and a blank body. Ideally, you'd want to trap the
> exception, return a InternalServerError (500) and perhaps a custom message
> for debugging.
>
> The proposed error handler certainly looks like a good fit for this. In the
> mean time is there an elegant alternative? (All I can think of is wrapping
> the plan/intent and trapping the exception).
>
> Cheers,
> Andrew
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://databinder.3617998.n2.nabble.com/Custom-Error-Pages-tp5958154p6034544.html
> To start a new topic under Unfiltered, email
> [hidden email]
> To unsubscribe from Unfiltered, click here.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Custom Error Pages

andrewoma
Thanks max!

This is the exactly the kind of thing I was thinking of.

Cheers,
Andrew
Loading...