-
Notifications
You must be signed in to change notification settings - Fork 226
Closed
Description
Throughout PSL, this is a common pattern:
try:
<do something>
except Exception as ex:
self.raiseException(ex, "Communication Error , Function : " + inspect.currentframe().f_code.co_name)
This makes troubleshooting difficult for several reasons:
- First and foremost, self.raiseException is not python3-compatible, so anytime it is called the original error is lost and an unrelated AttributeError is raised instead.
- self.raiseException is called from within classes which do not implement it (for example), which again loses the original exception and raises an unrelated one.
Even if the two above bugs are addressed, this type of custom exception handling reduces the amount of information normally available.
- Information on what happened is lost, since the exception type degenerates to a generic RuntimeError.
- Information on where it happened is lost, since every error is raised on line 4107 of sciencelab.py, instead of whereever the original exception was raised.
- It can inject false information about what happened. In the above try-except block, every exception is reported as "Communication Error", even though the except catches all exceptions, not just communication related ones.
- It increases cyclomatic complexity, making the code harder to understand and harder to unit test.
Python has excellent built-in exception handling, and as far as I can see PSL's custom implementation offers no advantages over it. What is its purpose?
Metadata
Metadata
Assignees
Labels
No labels