In the Try Catch shape, or any other shape for that matter, is there a way to detect the exception type being thrown?
I am not sure If you are asking the same- We can use the Base try/catch message and It will automatically identifies the exception that is being thrown If we use that in the exception shape in the catch path.
I mean an actual exception type, something I can put on a route or decision shape to handle different exceptions accordingly.
Something similar to the OOP construct:
throw new BatmanException("NaNa-NaNa-NaNa-NaNa-NaNa-NaNa-NaNa-NaNa")
throw new Exception("You'll never catch batman!");
catch (Exception ex)
//handle boring Non-Batman exceptions.
What about using the try/catch shape, with the exception shape throwing back Application Status Code or user defined message, and then route it accordingly in the catch shape?
I haven't looked at that. Does Try/Catch set the Application Status Code property? It's not always an Exception shape I'm trying to catch.
In the documentation it only mentions that Application Status Code is set by outbound connectors. I use it with HttpClient connectors to get the Http status codes from the response (ie status 200, 404, etc).
Meta informationdocument properties
You could do something like this:
In this process I send an empty message to Google Pub Sub.
If the message was okay, I would receive an Application Status Code 200.
From the Exception Shape I return the Application Status Code and the Application Status Message. That becomes the try/catch Message.
Hope it helps.
I ended up going with a similar implementation. I have an HttpResponse Handler process, and pass the connector result to it via process route. To make this work correctly, I created a Response Header Mapping in the connector:
The response document now has the Content-Type specified in it, and I can do some more robust response handling.
The default handler provides a number of features, including checking for http errors, and providing return routes by Content-Type. The routes are configured such that the "Default Return Documents" always returns, regardless of if one of the other routes returned a document or not. The result is similar to C#.NET's "finally" block, which is part of the "Try/Catch/Finally" error-handling structure. No matter what, as long as statusCode=200, the default path will always return the documents. This is to allow the parent process to manage how it handles unexpected content types, such as XML or HTML whenever JSON is expected - something which can easily happen when an endpoint crashes.
Retrieving data ...