Azure-iot-sdk-csharp: Code property on IotHubException is not populated

[Mikkelcv]

The property Code on IotHubException is never populated.

Like this:

try {
    await _serviceClient.InvokeDeviceMethodAsync(iotDeviceId, cloudToDeviceMethod);
} catch (DeviceNotFoundException ex) {
    var referenceCode = ex.GetReferenceCode(); //null
    var code = ex.Code; //ErrorCode.InvalidErrorCode
}

I have written the values I see when an error occur and it is always those values.

I would like to be able to get more detailed information on why the device was not found.
If I could get access to the error so it is possible to distinguish a 404001 DeviceNotFound from a 404103 "Timed out waiting for device to connect" as an example.

Thanks
Mikkel

AB#7291056

[timtay-microsoft]

Thanks for filing this issue. This seems like a bug on our side, so I'll look into why you are seeing this behavior.

[jenoola]

We made change in the latest SDK version, and now when error occurs, the whole stack trace is added to the log. This information should be sufficient for distinguishing errors.

[az-iot-builder-01]

@Mikkelcv, @jenoola, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey

[Mikkelcv]

The property remains on the exception object but is still not assigned any value, in the latest version.
I don't understand how this bug can be closed? The issue is still there.

[prmathur-microsoft]

As the latest SDK gives you the stack trace of the failure, we don't think we need to provide additional info other than that. What in in the information we provided on stack trace is missing for you?

[Mikkelcv]

The Code property would be used by us to differentiate cases that have different functional meaning to us, e.g. are the error transient or permanent. Cases include e.g. if the device is not connected (404103), the processing timed out on the device, the device has never been registered (404001) or internal errors on the IoT Hub.

We acknowledge that parsing stack trace to obtain this information is now possible. But it just seems to us as a very inefficient, but more importantly, fragile solution to parse such undocumented stack trace. At least it is not something that we want to try to do in our production code. So if this is still the only option that we have, we will continue with a generic error handling on our side.

But it still puzzles us that the ErrorCode property still exists in the latest version if it is never set? Shouldn’t it be removed or is the intention to have it set in a future release? Or is it used in some scenarios that we are not experiencing?

[prmathur-microsoft]

I understand your concern with having to parse the stack trace. But at the moment my recommendation is to use generic exception and very soon (in possibly next version of SDK) we will have a better architecture for exception handling and you wouldn't have to parse stack trace or use generic exception.

At the moment we expose retry options which takes care of retriable error scenarios like transient errors, throttling etc. And we throw non retryiable errors like the ones we mentioned to the user. But getting to the specifics about what the non retriable error is needs more detailed exception handling in our SDK. While just exposing the Code property might be an easy option, we have to gather the relevant code property from across all different protocols and map it to something that translates for an app user to understand it. Note we support three protocols. This is perhaps a significant code change and we are not prioritizing it for this SDK. However we will definitely have a better solution for it in the next version of this SDK. At the moment unfortunately either gathering the more generic exception or tracing via stack are the two options you have.

[Mikkelcv]

Thank you for the explanation.
We will see what we can do for now and then keep an eye on this better exception handling that will hopefully be part of the SDK.

Lets close it here then.
Thanks.

[ggirard07]

Can someone please reconsider this to keep the issue open until a viable solution is implemented?

I think we can all agree that relying on parsing a stack trace to resolve an error is both dangerous and ineffective. All Azure SDKs I know about support proper error code reporting... Actually I can't even recall of any SDK at all recommending parsing a stack trace...

[timtay-microsoft]

Reopening this issue because the SDK should be exposing the full status code. Expecting users to parse a stacktrace is unreasonable

[barustum]

Leaving the issue open until a fix has been shipped.

[abhipsaMisra]

This has been fixed as of Microsoft.Azure.Devices v1.22.0