Standard Exception handling

[ssteiner]

Are there guidenlines on how we can expect error handling to work with the SDK?
I found that if I use the wrong cloud region, I'm getting an ApiException. It has a property ErrorContent which contains a raw JSON Document. In my errror

{"error":"invalid_client","description":"client not found","error_description":"client not found"}

So I'm wondering... is this json structure defined somewhere so that I can add parsing to it? And can I always expect to get an ApiException? So also if my app can't access the API because Internet access may be blocked or because DNS lookup failed. In fact when I cut Internet access on my dev box, I was getting an ArgumentNullException instead, leading me to think that I need to add exception handling for a whole bunch of exceptions.

[LighthouseMike]

Not sure if this helps - it sounds like you're having issues with authentication stuff, so I could be way off-base here - but with the Platform SDK (and anything JS in general), I generally like to use async/await, which makes errors in promises/callbacks "catchable" using plain old try/catch blocks: What I mean is...

async function getSomeData() {
    try {
        var data = await someApiObject.getConversationsFooBarBaz({ pageSize: 50 });
        return data.entities;
    } catch(error) {
        // Handle the error
        return [];
    }
}

EDIT: Whoops, sorry, I noticed you're working with a C# SDK... but try/catch is a thing in C#, and you can even catch specific types of exception... HTH

[ssteiner]

Yeah, sure you can wrap in try/catch, but it's c# so exceptions are typed, and it's good to know what kind of exceptions you can expect as you want to work with the most specific one. Catching the ApiException is better than just catching the Exception. This is something I'd expect to see in the getting started guide but unfortunately cannot find. A catch(Exception e) is a last resort thing. I want to have more meaningful errors when possible. E.g. when using httpClient, you'd catch NetworkExceptions, process them, and return something like DNS lookup failed, or 'Server not reachable'.

In java, you have to register which Exceptions a method can throw. Since C# doesn't have that, having a list of expected exception types would be very useful. The alternative is that you have to trigger every exception you can think of, implement handling for it, and you can be sure you'll never catch them all. An ArgumentNullException when network isn't there, is something rather unexpected - you don't normally get that, you'd get some kind of NetworkException. So that alone is a strong hint that you'd encounter other non standard exceptions.