Refactor Parser Error Handling

[azaleacolburn]

Description

The synthesis parser in the exporter now properly handles the errors it was catching, instead of always printing the stacktrace to the user, it now displays clean errors in most cases. This PR also removes the logging wrapper that was previously being used essentially to wrap everything in a try-catch. Errors now propagate through the parser as values with a new Result class which is inspired by the Rust enum of the same name. Each error contains a message and a severity (Fatal or Warning), the latter refers to the severity on the entire parsing process, so an error might cause a function to completely fail, but the error can be recovered by a parent function. On instantiation, each Err automatically logs itself based on it's severity. For errors that are not even fatal for the originating function, an Err should be instantiated but not returned, as to not break control flow.

While some were obvious, for several functions, I wasn't entirely sure how/why they would fail (despite them being marked as fallible with logFailure), so for those ones, we'll need to switch to the Result-based error handling system as we find errors.

Objectives

• Result implementation
• Document Result, Err, and Ok classes
• Replace old error handling with nicer alternative (both for the user and developer)
  • Components.py
  • Materials.py
  • JointHierarchy.py
  • Joints.py
  • PDMessage.py
  • PhysicalProperties.py
  • RigidGroup.py(unsure)
  • Utilities.py
• Put checks after every opaque fusion function. This should probably be it's own PR.

Testing Done

• Successfully exported Dozer

JIRA Issue

[autodesk-chorus]

Chorus detected one or more security issues with this pull request. See the Checks tab for more details.

As a reminder, please follow the secure code review process as part of the Secure Coding Non-Negotiable requirement.

[BrandonPacewic]

Looking good.

In JointHierarchy.py there are still some exceptions that are following the old pattern:

synthesis/exporter/SynthesisFusionAddin/src/Parser/SynthesisParser/JointHierarchy.py

Lines 224 to 226 in 1121ac6

	if self.grounded is None:
	gm.ui.messageBox("There is not currently a Grounded Component in the assembly, stopping kinematic export.")
	raise RuntimeWarning("There is no grounded component")

This is causing the message box to display with the error AND the full traceback being showed to the user which was the previous behaviour of our logger. Not really sure how we should update this since it's within an init but we maybe could avoid showing the full traceback to the user and confirm that the export is actually being stopped as described by the messagebox.

[azaleacolburn]

Looking good.

In JointHierarchy.py there are still some exceptions that are following the old pattern:

synthesis/exporter/SynthesisFusionAddin/src/Parser/SynthesisParser/JointHierarchy.py

Lines 224 to 226 in 1121ac6

	if self.grounded is None:
	gm.ui.messageBox("There is not currently a Grounded Component in the assembly, stopping kinematic export.")
	raise RuntimeWarning("There is no grounded component")

This is causing the message box to display with the error AND the full traceback being showed to the user which was the previous behaviour of our logger. Not really sure how we should update this since it's within an init but we maybe could avoid showing the full traceback to the user and confirm that the export is actually being stopped as described by the messagebox.

Ya this is a tricky one. I think the way to go is to log the message (with the Err class), display a message box, then just remove the logging decorator and close the program quietly without logging the full traceback.

[BrandonPacewic]

I pushed a change that reverted a PWM icon update as the file was being replaced with a question mark. I also merged dev and fixed some merge conflicts.

1. It still looks like we are showing the full traceback upon a rigid component not being detected.
2. I'm getting an issue where the file name of an exported design is starting with a v.

[azaleacolburn]

It still looks like we are showing the full traceback upon a rigid component not being detected.
This is caused by the logFailure decorator around ConfigureCommandExecuteHandler.notify method, which initializes and calls the Parser. To fix this, I just put a try block around the Parser usage with an except block that just passes.