[SYNPY-1581] remove try: except: blocks that log and raise exceptions

[SageGJ]

Problem:

When client functionality was called by a user and wrapped in a try: catch: block, the exception was caught but the exception trace was still displayed. This behavior was undesirable by the user who expected no trace to be displayed since she had implemented her own error handling.

Solution:

The functionality in the wrapper that logs and raises exceptions was removed to allow exceptions raised in wrapped async methods to be handled by the caller or within the client by the interpreter instead of having an intermediary that always logs and raises exceptions, which is undesirable by some users
Design Doc

Testing:

testing was done with a mre adapted from the linked ticket. When executed no trace is displayed and the exception is caught

[BryanFauble]

@SageGJ When you get a chance do you mind rephrasing the PROBLEM portion of the PR description. This is more so the solution was implemented. Problem should ideally focus on the reasons why this change took place

[SageGJ]

On the initial run, there was a test failure that was not present on subsequent runs. On the next run tests were canceled despite none of the other tests failing. has this behavior been observed before?

[BryanFauble]

LGTM!

[thomasyu888]

On the initial run, there was a test failure that was not present on subsequent runs. On the next run tests were canceled despite none of the other tests failing. has this behavior been observed before?

@SageGJ I did not look deeply into the failed test but I'll just add that through observation there are flakey tests due to parallel execution of tests that interact with Synapse resources. Due to this, it sometimes causes conflict and the tests fail. It passes when you turn it off and on again.

I also think CI that is running are automatically canceled when you push a new commit? (I could be wrong)

[BryanFauble]

On the initial run, there was a test failure that was not present on subsequent runs. On the next run tests were canceled despite none of the other tests failing. has this behavior been observed before?

@SageGJ I did not look deeply into the failed test but I'll just add that through observation there are flakey tests due to parallel execution of tests that interact with Synapse resources. Due to this, it sometimes causes conflict and the tests fail. It passes when you turn it off and on again.

Yup!

I also think CI that is running are automatically canceled when you push a new commit? (I could be wrong)

Thats right

[SageGJ]

I did not look deeply into the failed test but I'll just add that through observation there are flakey tests due to parallel execution of tests that interact with Synapse resources. Due to this, it sometimes causes conflict and the tests fail. It passes when you turn it off and on again.

Perfect, thanks for that context @thomasyu888 !

I also think CI that is running are automatically canceled when you push a new commit? (I could be wrong)

There's only one commit in this pull request, the subsequent tests were triggered manually through the actions tap in the repo

cc @BryanFauble