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

Missing Request Type Exception #49

Closed
michaeljfarr opened this issue Sep 4, 2022 · 5 comments
Closed

Missing Request Type Exception #49

michaeljfarr opened this issue Sep 4, 2022 · 5 comments
Labels
enhancement New feature or request
Milestone

Comments

@michaeljfarr
Copy link

michaeljfarr commented Sep 4, 2022

Thanks again for a great project.

At the moment in Send in Mediator.g.cs the default handler is to ThrowArgumentNullOrInvalidMessage which first casts the message as global::Mediator.IMessage. Since the request doesn't need to be IMessage it can come through as null at that point, and then we get an ArgumentNullException message instead of a missing request type exception.

Possibly the issue I'm referring to could be fixed by not casting to IMessage? This would do MissingMessageHandlerException which would be good enough for my purposes. (I'm not sure if distinguishing between missing handler and a missing request type is possible or sensible, but they look like they could be different things)

(I am on 2.0.27-rc)

@martinothamar
Copy link
Owner

Hey, sorry about the delay here.. Is this about having a better error message for when a non-IMessage is sent? E.g. if I tried to send an ìntthrough the overload which takesobject`? I could probably have a better error message for that, maybe even Roslyn diagnostics would be better

@michaeljfarr
Copy link
Author

Hi - all good.

Yes, this is just about having a better error message. At the moment it is possible to get an ArgumentNullException during the send - and that can just make diagnosing things a bit difficult.

So, in Mediator.sbn-cs if instead of just casting to IMessage and then throwing ArgumentNullException - it could check whether msg was null. The error message could then say that msg.GetType() was not assignable to IMessage to be clearer and help debugging (or something along those lines).

@martinothamar
Copy link
Owner

Good point, thanks, will get this sorted as soon as I have time

@martinothamar
Copy link
Owner

refactored some error handling here, so it's more specific and clearly defined: #66
will be part of 3.0 release since its a breaking change

@martinothamar martinothamar added the enhancement New feature or request label Jun 21, 2023
@martinothamar martinothamar added this to the 3.0 milestone Jun 21, 2023
@martinothamar
Copy link
Owner

Merged the PR

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