Since MacroDroid is not a text-based editor, but only allows you to setup block via its own interface, you can't possibly run into any type error, index out of bound error, math error or any other kind of error you would have to face when writing a real code. Only fuck up that you could make is running actions in a loop without delay and thus lagging MacroDroid or possibly your whole phone or you could face a MacroDroid inner bug itself where the block wouldn't work as expected.
So that's why try and catch block don't make sense in MacroDroid, because there's nothing to catch. MacroDroid macro can't just naturally run into an exception that would stop the whole Macro from running. The only cases I can think of, where block could return you, an exception is with the HTTP request action and intent action, but these are just outputs of actions that are counting on these cases and will return the answer as if nothing happened.
EDIT: Thinking about this, there are logs logged into MD's system log that could be count as exceptions. Those are the cases when MacroDroid can't access the camera, location or has some other kind of executing the action. It was proposed by
@Jacob L to add a system log trigger, which I think is not a bad idea.
This can mean that if there are errors, action can be taken to fix them. For example, It is possible to restart the accessibility services with ADB
www.macrodroidforum.com