UserError doesn't accept Exception type as input (Backwardscompatibility issue)

Which tool versions are you using?

SDK: v13.7.0
Python: v3.10
Isolation mode: venv

Current Behavior

WIth the userexception it was quite common to re-raise an error using a structure like this:

try:
   # do something
except ValueError as errormessage:
    raise UserException(errormessage)

With the new UserError this is causing a new error: only string type is accepted as message.

This means that a lot of old code is not working correctly anymore.

Workaround/Fix

It’s pretty easy to fix, but I didn’t expect it to be necessary:

try:
   # do something
except ValueError as errormessage:
    raise UserError(str(errormessage))

Expected Behavior

Backwards compatible code or a proper codefix.

1 Like

Interesting find. Thanks for sharing. I created an internal issue for it.

Although I understand that you did not expect this behavior to change, i find it difficult to understand why you would want to use the pattern you described. Can you explain why this pattern is desired?

try:
   # do something
except ValueError as e:
  raise UserException(e)

If you catch and re-raise as UserException:

  • the user gets to see a potentially cryptic error message containing python terminology
  • the user cannot press the “report problem” button and send you the stacktrace (would be the case without except)

EDIT: one usecase could be if you raise the ValueError yourself as a control flow mechanism. Then it would make sense, but in that case i would expect it to be a custom Exception type such that you make sure you don’t accidentally catch other errors

The way you describe it in the “EDIT” is exactly the use case that I aim for. I’ve used a ValueError here to make it easy to reproduce, but for a custom Exception it wouldn’t work either. In the case of a ValueError: I think the error message almost never is very cryptic and is very useable to reraise as UserError. Especcially when the code block in side the ‘try’’ statement are not really dependent on third-party packages.

The reason why you would like to use such a pattern is because I like to keep the “viktor” logic as separated as possible from my custom modules. In this way the custom modules not depending on the viktor-platform and can be (re) used in any desired way. It also benefits maintenance (imagine some party replacing the UserException with a UserError ;-)). Reraising (custom) errors as UserError is the result of working that way.

1 Like

Thanks for your clarification!

This was fixed in SDK v13.7.1

1 Like