[Twisted-Python] Appropriate exception for AMP types receiving garbage?
![](https://secure.gravatar.com/avatar/415203f2727ceaf56d8f7f5e6d5d508b.jpg?s=120&d=mm&r=g)
Hi, I'm writing a custom AMP type. I noticed that when writing the unit test for garbage input, I didn't really know what exception to check for. I couldn't find any place where this was formally defined, so I checked for implementation behavior. Boolean explicitly raises TypeError. Integer raises ValueError, but that appears to only be an implementation detail of int. It could also be that it doesn't matter at all, but it does seem a little strange that Integer and Boolean raise different exceptions when fed garbage... -- cheers lvh
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Dec 26, 2012, at 1:43 PM, Laurens Van Houtven <_@lvh.cc> wrote:
Hey Laurens, This is basically a feature request :). There's no particular defined error type for argument parse errors in AMP. It's not a bad feature though. The exception also doesn't go anywhere useful - the only contract is basically that it'll bubble up and break the connection if you get some bad data. A more sophisticated and trappable / trackable way to propagate this sort of error would be useful. (I would personally consider it a compatible change if the behavior of the error cases changed here, on the grounds that anything that uncontrollably logs a traceback in response to network input is a gross spec violation of a sort. Maybe we should add an explicit exemption for that case.) -glyph
![](https://secure.gravatar.com/avatar/415203f2727ceaf56d8f7f5e6d5d508b.jpg?s=120&d=mm&r=g)
How about something like {_error: 1, _error_code: BAD_ARGUMENT_VALUE, ...}? I was writing something to constrain AMP Argument's in- and output values: https://github.com/lvh/txampext/blob/master/txampext/constrained.py ... and my users getting a real exception as opposed to a disconnected transport would be nice :) Any ticket suggestions welcome. On Thu, Dec 27, 2012 at 8:02 AM, Glyph <glyph@twistedmatrix.com> wrote:
-- cheers lvh
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Dec 26, 2012, at 1:43 PM, Laurens Van Houtven <_@lvh.cc> wrote:
Hey Laurens, This is basically a feature request :). There's no particular defined error type for argument parse errors in AMP. It's not a bad feature though. The exception also doesn't go anywhere useful - the only contract is basically that it'll bubble up and break the connection if you get some bad data. A more sophisticated and trappable / trackable way to propagate this sort of error would be useful. (I would personally consider it a compatible change if the behavior of the error cases changed here, on the grounds that anything that uncontrollably logs a traceback in response to network input is a gross spec violation of a sort. Maybe we should add an explicit exemption for that case.) -glyph
![](https://secure.gravatar.com/avatar/415203f2727ceaf56d8f7f5e6d5d508b.jpg?s=120&d=mm&r=g)
How about something like {_error: 1, _error_code: BAD_ARGUMENT_VALUE, ...}? I was writing something to constrain AMP Argument's in- and output values: https://github.com/lvh/txampext/blob/master/txampext/constrained.py ... and my users getting a real exception as opposed to a disconnected transport would be nice :) Any ticket suggestions welcome. On Thu, Dec 27, 2012 at 8:02 AM, Glyph <glyph@twistedmatrix.com> wrote:
-- cheers lvh
participants (2)
-
Glyph
-
Laurens Van Houtven