Skip to content

TryFindMethod throws AmbiguousMatchException for overloaded method names instead of returning a result #155

Closed

Description

@matt-edmondson

What's wrong

ReflectionExtensions.TryFindMethod calls methodOwner.GetMethod(methodName, bindingFlags) at Extensions/ReflectionExtensions.cs:34 with no handling for overloads. When the name is overloaded at any level of the type hierarchy, GetMethod throws AmbiguousMatchException and the exception escapes the Try method.

Reproduction (run against a local build)

  • typeof(string).TryFindMethod("Split", BindingFlags.Public | BindingFlags.Instance, out _) throws AmbiguousMatchException.
  • A base class with private void Foo(int) and private void Foo(string), searched from a derived type with NonPublic | Instance, also throws.

Why it matters

The repo's CLAUDE.md says the Try* methods report through a bool rather than throwing. A caller that probes for a method by name (plugin or convention discovery, for example) crashes on any overloaded name. The existing tests only use names that are not overloaded.

Suggested fix / acceptance criteria

  • The method never throws for an existing overloaded name.
  • Pick one of these:
    • resolve the overload deterministically, for example by checking GetMethods(... | DeclaredOnly) filtered by name at each level, and document the rule; or
    • add an overload that takes Type[] parameterTypes, and document that the name-only form returns false (or a defined choice) when the name is ambiguous.
  • Add tests for both repros above.

Activity

  1. matt-edmondson commented on Oct 6, 2026

    @matt-edmondson
    ContributorAuthor

    Triage

    • Category: Bug
    • Priority: Medium. A Try* method throws, which breaks the library's documented contract. Any caller that probes for a common overloaded name, such as string.Split, crashes. There is a workaround (wrapping the call in a try/catch), so this is not High.
    • Area / suggested owner: ReflectionExtensions.TryFindMethod.
    • Duplicates: None found.
    • In progress: No open PR covers it.
    • Next step: Either resolve overloads deterministically per hierarchy level using GetMethods(... | DeclaredOnly), or add a Type[] parameterTypes overload and return false on ambiguity. Document the rule and add tests for both repros.

    Generated by Claude Code

  2. added a commit that references this issue on Oct 14, 2026
    19782f2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions