Subclasses of this exception are thrown by all the methods accessible through DegreeDaysApi to indicate problems like network failure, service failure (our server-side processing going wrong), a rate limit being reached, invalid authentication credentials, and other types of exception that are specific to the API operation in question.
The likelyhood of many of these exceptions occurring will depend on how you are using the API. For example, if your customers install your application and then enter their own API access keys into it, you might expect the odd InvalidRequestException because of typos. However, such an exception would be less likely to occur if your application was a centrally-running background process that used a single API account to collect data. And consequently you might be less likely to want to handle InvalidRequestException explicitly.
So a typical approach would be to catch just those subclasses that you're interested in (if any), catching DegreeDaysApiException last as a kind of catch all, or just letting any unhandled exceptions bubble up the call stack.