Except¶
Evaluate the try body while guarding for exceptions.
If an exception occurs, the provided lists of exception types are checked in order to see if the exception is of one of the types listed. If so, the corresponding except body is evaluated, and otherwise the next list of exception types (if any) is checked. The result of the Except node is then either the result of the try body (if it succeeded), or the result of the triggered except body if an exception occurred. If a finally body is provided, it is always evaluated after the try body and the except body (if any). If the finally body is configured to have a placeholder, then the finally body may transform what would otherwise be the result of the Except node; otherwise, the finally body is only invoked for side effects (e.g., deleting a file created by the try body) and the finally body's return value is ignored. More Info... Version 1.0.0
Ports/Properties¶
try_body¶
Body to execute with exception guarding.
try_body__signature¶
Optional slotname of a placeholder that marks the beginning of the try body. The try body is a subgraph which is executed normally, except that any exception that occurs is caught and handled by the exception handlers (if any). The last node of that subgraph is wired into the Except node's "try_body" port, which makes it run under the control of the Except node. In graphical UIs this edge will show as dotted to indicate that this is not normal forward data flow but a subgraph (i.e., the try body) is being passed to the Except node. If no exception occurs, the try body's return value is returned as the result of the Except node. To limit the scope of the try body, you can specify the name of a placeholder node here on which the try body depends (for example, (try) instead of (~)). Then, only nodes downstream of this placeholder node will be part of the try body. Otherwiese, the try body will be the upstream graph and any of its downstream "loose ends".
handler1¶
Exception handler 1.
handler2¶
Exception handler 2.
handler3¶
Exception handler 3.
handler4¶
Exception handler 4.
handler5¶
Exception handler 5.
finally_body¶
Finally handler.
finally_body__signature¶
Optional input argument name of the finally body. By default, the finally body (if one is provided) accepts no arguments and is therefore only evaluated for its side effects (e.g., printing a message or closing a file), which generally happens after the try body and any triggered exception handler nodes have run, whether an exception occurred or notm and whether it was caught or not. The finally body's return value is ignored. However, if you specify a name here (e.g., (finally) instead of (~)), then the finally body must also contain a Placeholder node whose slotname matches this name, and the placeholder will receive what would normally be the return value of the Except node, and the body is allowed to transform that value (e.g., by returning a different value). Note that the normal return value of the Except node is either the return value of the try body (if it succeeded) or that of the exception handler that was triggered. The last node of the finally body is then wired into the Except node's "finally_body" port. In graphical UIs this edge will show as dotted to indicate that this is not normal forward data flow but a subgraph (i.e., the finally body) is being passed to the Except node. The value returned by that final node is then also returned as the result of the Except node. If no exception handler triggered, then the Except node has no return value since it will throw an exception; in this case, the finally body receives a None value as its input argument.
result¶
Result of the operation.
bypass_if_debugger¶
Bypass exception handling if a debugger is attached. This can be used to allow exceptions to "fall through" so that they can be intercepted by the debugger. Note that the finally clause, if any, will still apply.
exceptions1¶
List of exceptions to catch in handler 1. To catch no exceptions, you can clear this value to an empty list, i.e., []. This can list any exception type, including custom ones. You can find a listing in the Throw node's list of predefined throwable exceptions. If none of the listed types match the exception thrown by the try body, the next handler is tried. However, keep in mind that this means that, if your first handler is a broad exception handler that catches all exceptions (such as the default type Exception), then the other handlers will never be tried.
exceptions2¶
List of exceptions to catch in handler 2.
exceptions3¶
List of exceptions to catch in handler 3.
exceptions4¶
List of exceptions to catch in handler 4.
exceptions5¶
List of exceptions to catch in handler 5.
set_breakpoint¶
Set a breakpoint on this node. If this is enabled, your debugger (if one is attached) will trigger a breakpoint.
metadata¶
User-definable meta-data associated with the node. Usually reserved for technical purposes.