Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Allow Java devices to customize action errors
30-07-2012, 10:35 AM
Post: #3
RE: Allow Java devices to customize action errors
(30-07-2012 08:25 AM)simonc Wrote:  Most of these changes sound good and I'll be happy to apply them. I don't want to introduce differences in behaviour between language bindings though; this would make overview documentation far harder. So if you want to be able to set error codes outside the 800s, you'll need to convince me that the C#/C++ APIs are deficient and should be fixed :-).

I thought the device architecture doc only allowed for errors between 800-899. Where does 710 - Invalid Container ID come from? Is this another case where the media server device description implies changes to the spec without going to the trouble of actually updating the spec itself?

The UPnP Device Architecture 1.1 and the ContentDirectory:1 Service Template 1.01 are consistent on what errors can be returned by a device.

In Table 3.3 on page 82 of the UPnP Device Architecture 1.1 spec, the listed errors 600 through 605 can be raised by provider code. It should be possible for ohNet to take care of raising 602 errors, but it doesn't seem to do this at the moment.

Table 3.3 also reserves codes in the range 613-699 and 700-799 for definition by other UPnP specs. In Table 11 on page 35 of the ContentDirectory:1 spec, codes 701 through 720 are defined, and a ContentDirectory:1 implementation needs to be able to produce these error codes.

In both table 3.3 and table 11, codes 800-899 are reserved for use by UPnP vendors. So if a vendor is defining a proprietary service and needs some error codes for the actions of that service, these should go in the 800-899 range.

Quote:Regarding control point retrieval of error details, I agree that this is desirable but don't think it'll be as simple as exposing Invocation::iError. Wouldn't you want the info from the FaultCode xml in the action response? To guard against me implementing the wrong thing, can you describe how you'll use this info please? A complete enumeration of the error cases you want to handle (or expose to users) would be very useful.

The information that I'd like to see is the error code and error description. This information is present in the Error object and can be retrieved by the Code() and Description() methods. So if the Java or C# bindings have some way of getting the Error object, they should be able to add this information to the ProxyError object that's thrown to user code.

These errors might be standard errors defined by the UPnP specs or they might be properietary errors defined by a proprietary service. At a minimum, I think the control point would want to log the error code and description to aid problem determination. For some errors such as 603 and 605, it may be possible for the control point to modify and/or retry the request. For error 604, the control point should report this through its UI. For error 602, the control point may be able to work around the lack of device support for an optional action by invoking some other action or limiting the functionality that it provides to the user.

For the ContentDirectory:1 service, errors 701 and 710 might indicate that the control point's cache of server container data is out of date (for example, following a server rescan) and needs to be refreshed from the root container.

For proprietary services that use errors in the 800-899 range, there are likely to be similar cases where some errors can be recovered by the control point.
Find all posts by this user

Messages In This Thread
RE: Allow Java devices to customize action errors - simoncn - 30-07-2012 10:35 AM

Forum Jump: