unicode decode error

15 views
Skip to first unread message

Ubaldo Huerta

unread,
Oct 17, 2011, 7:16:10 AM10/17/11
to google-prot...@googlegroups.com
You can't have a (non ascii encoded) unicode string as application error. It blows up.

raise remote.ApplicationError(u"This is UTF-8 encóded string")  # exception thrown

 If you pass it a byte string, it blows up as well. 

byte_string = unicode_string.encode('utf-8')

raise remote.ApplicationError(byte_string)  # exception is also thrown

It' a shame because I was trying to use this value to display error in client side. Instead have to resort to put this strings in the service return message.

It'd be nice if it gets fix in the next SDK revision :-)

Rafe Kaplan

unread,
Oct 18, 2011, 2:05:15 PM10/18/11
to google-prot...@googlegroups.com
It's true, you cannot use ascii encoded characters for the error
message or error name. It is the intent that in the future it will
allow for binary content, but the details need to be worked out.
Here's the master plan so you can have some idea about where it might
go. Please see remote.RpcStatus for the the definition of the error
message class.

I'm hoping to make it possible to actually defined application
errors with user defined content. For example:

class ResourceNotAvailable(remote.ApplicationError):

resource_name = messages.StringField(1)

There will be a field bytes field on RpcStatus that will accept an
encoded version of ResourceNotAvailable. This field can then contain
another bytes field if that's what you need.

The thing that's preventing this from moving forward easily is that
it needs to have a design that will not break compatibility with the
protobuf standard. In particular, I would like to be able to describe
an application error using the classes found in descriptor. Make
sense?

Ubaldo Huerta

unread,
Oct 20, 2011, 6:29:17 AM10/20/11
to google-prot...@googlegroups.com
Yes, the scheme of extending RemoteError makes perfect sense to me.

Thanks
Reply all
Reply to author
Forward
0 new messages