non-retryable-err-types exercise #4
Conversation
exercises/non-retryable-err-types/practice/Workflow/PizzaWorkflow.cs
Outdated
Show resolved
Hide resolved
exercises/non-retryable-err-types/practice/Workflow/Activities.cs
Outdated
Show resolved
Hide resolved
exercises/non-retryable-err-types/practice/Workflow/Activities.cs
Outdated
Show resolved
Hide resolved
Bumps [ch.qos.logback:logback-classic](https://github.com/qos-ch/logback) from 1.4.8 to 1.4.12. - [Commits](qos-ch/logback@v_1.4.8...v_1.4.12) --- updated-dependencies: - dependency-name: ch.qos.logback:logback-classic dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [golang.org/x/net](https://github.com/golang/net) from 0.22.0 to 0.33.0. - [Commits](golang/net@v0.22.0...v0.33.0) --- updated-dependencies: - dependency-name: golang.org/x/net dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
exercises/non-retryable-err-types/solution/Workflow/Activities.cs
Outdated
Show resolved
Hide resolved
| logger.LogError("Unable to process credit card: {Message}", err.Message); | ||
| throw new ApplicationFailureException( | ||
| message: "Invalid credit card number error", | ||
| details: new[] { order.Customer.CreditCardNumber }); |
There was a problem hiding this comment.
Are you sure you want to swallow the error and stack trace and such from where the activity actually errored? You can make it the inner exception or something. For most users, catching an error just to rethrow it is unnecessary unless the caller really needs it a certain way. Also, for many users, catching an error just to log it and rethrow may be unnecessary.
There was a problem hiding this comment.
This is a good callout. We have some content in the course content about swallowing exceptions and the consequences of doing so. This is currently how this portion of the exercise does it in all the other language courses, so for now we're going to swallow the error here. We have created a ticket, EDU-3826, to re-evaluate this section of the code during our next maintenance period and see if we want to update it, or at the very least, call out in the README that we are intentionally swallowing the exception here. Thanks for the suggestion 😄
…ent a reusable class, still need to address try/catch
No description provided.