Closed diegodfsd closed 7 months ago
Hi @diegodfsd , no unfortunately the raw Exception
s had to go to enable distributed error tracking.
Can you tell me more about which situation you need the real exception objects? Maybe I can help you figure out a workaround...
How fortuitous: I actually have a similar question.
Previously we've used exception metadata to return status codes or determine severity. For instance, we might have a StatusCodeException
that is returned with IFailed<MyMessage>
whose property StatusCode
can help us generate the appropriate AbortSessionRequest
message type to publish on the bus. (Or something like that.)
I'd be happy to hear about better ways to do this, but in the meantime ExceptionInfo
is lacking a good way to encode metadata such as exception properties or Exception.Data
information.
I understand we want ExceptionInfo
to be more serializable and generic to accommodate distributed error tracking, but it seems like a richer object is necessary, and better conversions to/from exceptions might be nice, too. My current approach is to marshal ExceptionInfo
into a Problem Details structure, with some custom "extensions" for my specific metadata needs. I was in fact planning to suggest that ASP.NET's ProblemDetails
might be a good alternative to ExceptionInfo
. (Or, if we don't want to include that namespace as a Rebus dependency, perhaps just a nice model for ExceptionInfo
to mirror. Specifically, the dictionary for extensions/metadata, and the fancy JSON serialization.)
With Rebus as it exists today, it looks like I have two practical options:
ExceptionInfo
.ExceptionInfo
, then implement my own IErrorTracker
to populate FailedMessageWrapper
. (Would this work?)Your thoughts and suggestions are most welcome!
We are also running into a similar issue where we used exception metadata to return information to our users. Say someone tries to modify data that's already been modified, we took the new data and sent it with the exception such that the user could be updated.
Iadenedge I've tried to (de)serialize the Details property but since it's an Exception.ToString()
it only returns the message and the stack strace, all of the metadata from the custom exception is lost.
Iadenedge I've tried to (de)serialize the Details property but since it's an
Exception.ToString()
it only returns the message and the stack strace, all of the metadata from the custom exception is lost.
Good point. It looks like customizing ExceptionInfo
requires a new IErrorTracker
in any case. Perhaps I will submit a PR to at least create an ExceptionInfo
factory. That might be helpful, since at least a few folks are looking for more than just ToString()
. (And the actual tracking of exceptions is orthogonal to their content.)
(Edit: draft PR opened.)
@mookid8000 I just tried to update the wiki with some information about the new ExceptionInfo system -- did you get that for approval? It kind of looked like it just deleted everything I wrote. ðŸ˜
Please let me know if there's a better way to update the wiki! (And Merry Christmas!)
aww bummer dude, I didn't get anything... where did you write it?
Oh wait, I'm stupid. It's there now: I added a section called Exception Information to the error handling page. Please feel welcome to add to, remove from or change it in any way! (Or I'm happy to take suggestions.)
I think we can also close this ticket. Hopefully @diegodfsd will be good to go with the new functionality. (I have successfully integrated it into our code and it works for us. Thank you again, @mookid8000!)
Hi Guys,
I saw that the issue was in good hands and now I am going to update my rebus version to use the new feature.
We updated Rebus to the latest version, and after following the instructions, everything is working fine for us.
Thank you so much for your help, @ladenedge and @mookid8000.
Hi @mookid8000,
Are there any ways to access the raw exception from IFailed or any other means in case of failure, considering we are upgrading to Rebus 8? Our current flow was created over Rebus recommendations where the raw exception is important data for us.