Comments on: rails exceptions in xml

By: Sarah

Sarah — Thu, 26 Nov 2009 19:32:52 +0000

That’s just a regular error I think, not thrown as an exception…

By: Josh Gum

Josh Gum — Wed, 25 Nov 2009 20:17:06 +0000

Sorry, was actually :

HTTP/1.1 422
Connection: close
Date: Wed, 25 Nov 2009 20:16:40 GMT
Content-Type: application/xml; charset=utf-8
Cache-Control: no-cache
Content-Length: 141

record_not_found
Couldn’t find Offer with ID=999

By: Josh Gum

Josh Gum — Wed, 25 Nov 2009 20:09:43 +0000

Sure.. What’s strange is your respond block was rendering HTML..? I’ve got the same thing setup and mine return json and xml.

curl -H ‘Accepts: text/xml’ -i http://127.0.0.1:3000/offers/999.xml
HTTP/1.1 422
Connection: close
Date: Wed, 25 Nov 2009 20:04:35 GMT
Content-Type: application/xml; charset=utf-8
Cache-Control: no-cache
Content-Length: 68

Internal Server Error Couldn’t find Offer with ID=999

By: Sarah

Sarah — Wed, 25 Nov 2009 20:03:00 +0000

Ok, maybe that’s a little more rails-y, but I’m not sure that it is more readable than just plunking the wrapper xml node into a string and inserting the exception.message with string interpolation as we did.

By: Josh Gum

Josh Gum — Wed, 25 Nov 2009 19:48:36 +0000

Try;

format.xml { render :xml => {:message => “Internal Server Error #{exception.message}”}.to_xml(:root => “error”), :status => 500}

format.json { render :json => {:error => { :message => “Internal Server Error #{exception.message}”}}, :status => 500

By: Wolfram Arnold

Wolfram Arnold — Thu, 24 Sep 2009 19:12:46 +0000

I like Erik Ostrom’s suggestion, but I would refine it to say that if the accept header calls for HTML Rails behaves as today, as many web sites rely on this Rails default to return an HTML error message.

Where Rails fails today is that is replies in HTML even if the accept header specifies something else (e.g. XML or JSON). In that case, the default behavior would probably be best to just return a status code and leave it to the application developer to add textual error messages.

By: Sarah

Sarah — Mon, 14 Sep 2009 02:27:23 +0000

Good point. I think empty content with a status code is a reasonable solution.

By: Erik Ostrom

Erik Ostrom — Mon, 14 Sep 2009 02:04:56 +0000

It seems reasonable that exceptions should always be returned in the format the client requests, but I’m not sure I’d want Rails to enforce this. Since XML is sort of a meta-format, it’s not enough to just have Rails return “something in XML”; it has to return something that conforms to the client’s expectations about how exceptions are rendered in XML. That’s application-specific.

(Or at least, uh, “specific-kind-of-XML-specific”. Like, if you’re using SOAP, that has its own exception protocol.)

Maybe when there’s an unhandled exception Rails should just return an HTTP error code with no content? Unless the application sets up an exception handler?

By: Sarah

Sarah — Sun, 13 Sep 2009 23:58:16 +0000

Yeah, I consider it a bug in my code that there wasn’t a validation on the model; however, I wanted to be sure if *any* code throws an exception that it is returned to the client as XML (because the client isn’t built to expect HTML as a response to an XML API nor should it be).

Certainly the exception is not caught and perhaps it should be by ActiveRecord, which could then populate @person.errors with the message from the database adapter.

By: Austin Putman

Austin Putman — Sun, 13 Sep 2009 23:48:04 +0000

Don’t know if its a bug per se. It’s odd as the database is doing validation in addition to the validations done by the model. I would say that if the 40 character limit is important, you could put an ActiveRecord validation in to prevent this situation. Then you will get the same error across all databases.

It surprises me that the controller logic doesn’t handle this case. Usually the database update is tested as a conditional:

if @person.save
respond_to # happy path block
…
else
respond_to # error message logic block
….
end

In your case, the save is throwing an error, like save!. The AR::Postgres adapter could maybe rescue that error and return false, but how can it represent the nature of the error in a way that is accessible to the controller?