Passing errors from subsystems to application code instead of simply printing them

[TheButlah]

What would be involved in supporting such a feature? It would be cool if the parent subsystem was able to explicitly handle the child subsystem errors.

[Finomnis]

Working on it :)

Currently hard to do due to implementation problems, but I'm working on a full rewrite.

The goal is to provide, additionally to a start function, a start_decoupled or similar. The difference will be that if an error/panic happens in the decoupled subsystem tree, it only stops the decoupled subtree instead of the entire program. The errors will then have to be passed on to the user.

I can't do both at the same time, though, because Errors usually don't implement Clone or Copy. Therefore I will attempt to have the decoupled subsystem that passes errors to the user, and the normal one that passes it upwards in the subsystem tree.

The background for that change is that I want to implement the ability to spawn one decoupled subsystem per connection, in servers. I will write an echo server that prints a goodbye message to all connected clients on shutdown.

Does that work towards your usecase?

I can't promise an ETA though, as this I obviously don't work full time on this project.

[TheButlah]

Conceptually a subsystem has only 1 parent, so why would the error need to be Clone/Copy? It can just Send it to the parent.

Not sure about the panic stuff, I'm too unfamiliar with now this library works to comment on that.

[Finomnis]

I think it will make sense when you see the API I have in mind :)

But yes, I plan to, instead of printing the errors, to return them in a wrapping error to the user.
The code of printing the errors will be moved to the Display impl of said error, giving the user full freedom over it. (That's at least my plan, we will see how things work out)

[Finomnis]

@TheButlah I didn't manage to make the error types configurable yet, but at least they are now attached to the error:

https://github.com/Finomnis/tokio-graceful-shutdown/blob/main/src/errors.rs

Does that help for your usecase?

[TheButlah]

Its a start, but the error type is still a trait object, which makes it hard to actually handle the error. For example, if the error is a thiserror enum, the application will want to pattern match on it. Its possible I suppose to cast with Any, but its not ideal

[Finomnis]

I'm still working on that, but it turns out to be much harder than expected.

If you want to follow, here:

• https://stackoverflow.com/questions/71980268/miette-how-to-specify-errors-that-contain-a-generic-that-defaults-to-boxdyn-e
• Using default template type for the #[source] field zkat/miette#162

It works if I ditch the neat error formatting with miette, and it works if I leave out the Box<dyn Error> as default, but it doesn't work if I want both.
I understand that there are convoluted workarounds, but I didn't succeed in implementing one yet.

If you know how to solve this, feel free to tell me ;)

[Finomnis]

@TheButlah how is this? #27

[Finomnis]

Let's continue this discussion here.