jstedfast/MailKit · error · ArgumentNullException
uri
Error message
uri
What it means
BodyPartCollection.IndexOf(Uri) throws ArgumentNullException when the uri parameter is null. The library requires a non-null Uri to search for the body part whose Content-Id or Location matches, so it fails fast instead of silently returning a bogus index. This follows the standard .NET convention for mandatory arguments.
Solutions
- Ensure the Uri passed to IndexOf is non-null; check for null before calling.
- If the value may be a string, parse it with Uri.TryCreate and only call IndexOf when parsing succeeded.
- If null legitimately means 'no reference', skip the IndexOf call and handle the absence explicitly instead.
Example fix
// before var index = bodyParts.IndexOf(cidUri); // after var index = cidUri is null ? -1 : bodyParts.IndexOf(cidUri);
Defensive patterns
Strategy: validation
Validate before calling
if (uri is null)
return -1; // or handle absence explicitly
var index = bodyParts.IndexOf(uri); Type guard
bool HasCidUri(Uri? uri) => uri is not null && uri.IsAbsoluteUri && uri.Scheme.Equals("cid", StringComparison.OrdinalIgnoreCase); Try / catch
try {
index = bodyParts.IndexOf(uri);
} catch (ArgumentNullException ex) {
// ex.ParamName == "uri"; treat as 'no reference to search for'
index = -1;
} Prevention
- Parse cid references with Uri.TryCreate and skip failures instead of passing null.
- Use nullable reference types (Uri?) and check for null before calling IndexOf.
- Never assign lookup results that may be null directly to variables consumed by MailKit APIs.
When it happens
Trigger: Calling BodyPartCollection.IndexOf(Uri) with a null Uri reference, e.g. passing an unset field or the result of a lookup that failed to produce a Uri (indexOf(null)).
Common situations: Developers resolve a cid: URI from message text or a config value, and the parsing step returns null (unparseable cid, missing Content-Id); they then pass the null Uri straight into IndexOf without checking.
Related errors
AI-assisted analysis of jstedfast/MailKit@9d3859a785 (2026-09-15).
Data as JSON: /api/errors/1773e1a10021d006.
Report an issue: GitHub.
Appendix: source
Thrown at MailKit/BodyPartCollection.cs:210
/// </summary>
/// <remarks>
/// <para>Finds the index of the body part matching the specified URI, if it exists.</para>
/// <para>If the URI scheme is <c>"cid"</c>, then matching is performed based on the Content-Id header
/// values, otherwise the Content-Location headers are used. If the provided URI is absolute and a child
/// part's Content-Location is relative, then then the child part's Content-Location URI will be combined
/// with the value of its Content-Base header, if available, otherwise it will be combined with the
/// multipart/related part's Content-Base header in order to produce an absolute URI that can be
/// compared with the provided absolute URI.</para>
/// </remarks>
/// <returns>The index of the part matching the specified URI if found; otherwise <c>-1</c>.</returns>
/// <param name="uri">The URI of the body part.</param>
/// <exception cref="System.ArgumentNullException">
/// <paramref name="uri"/> is <see langword="null" />.
/// </exception>
public int IndexOf (Uri uri)
{
if (uri == null)
throw new ArgumentNullException (nameof (uri));
bool cid = uri.IsAbsoluteUri && uri.Scheme.Equals ("cid", StringComparison.OrdinalIgnoreCase);
for (int index = 0; index < Count; index++) {
if (this[index] is not BodyPartBasic bodyPart)
continue;
if (uri.IsAbsoluteUri) {
if (cid) {
if (!string.IsNullOrEmpty (bodyPart.ContentId)) {
// Note: we might have a Content-Id in the form "<id@domain.com>", so attempt to decode it
var id = MimeUtils.EnumerateReferences (bodyPart.ContentId!).FirstOrDefault () ?? bodyPart.ContentId;
if (id == uri.AbsolutePath)
return index;
}
} else if (bodyPart.ContentLocation != null) {
if (!bodyPart.ContentLocation.IsAbsoluteUri)View on GitHub (pinned to 9d3859a785)