Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipes for Error Handling #75

Open
Hollow-Ego opened this issue Oct 17, 2022 · 0 comments
Open

Pipes for Error Handling #75

Hollow-Ego opened this issue Oct 17, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@Hollow-Ego
Copy link

Is your feature request related to a problem? Please describe.
There are at least two scenarios where you might need a pipe. In both case the pipe should act upon the error details before before it's passed down to observers or even cancel any further handling

Scenario 1:
Before you even handle any errors you want to check additional conditions. For example you might want to ask the user if they want to submit this report in the first place.

Scenario 2:
Before the error details reach the observers you want to add additional information, like an internal app version. This is specifically for those kind of information that you would need for every log and would otherwise need to add in every single observer. There is also the option to remove certain information.

This feature goes along well with my other feature request (#74), so they could both use a context property.

Describe the solution you'd like
When initializing talker you can provide a new property "pipes", which is an array of TalkerPipes. The order of the pipes should dictate the execution order. A TalkerPipe can either cancel any further execution or attach additional information.

The overall flow would look like this:

  1. talker.handle is called with some parameters
  2. Talker builds a TalkerException object
  3. Talker passes that object through the pipelines
  4. If the execution was not canceled, the object is handled by the observers

In the end observers have an enriched TalkerException.

Describe alternatives you've considered
You would have to add the wanted logic to all observers, which is a lot of redundant code. So no real alternative as far as I know.

Additional context
The idea of having a way to add information to all error details is based on Serilog Enrichers.

@Frezyx Frezyx added the enhancement New feature or request label Jun 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants