dotnet/wpf · error · ArgumentNullException

The exception argument cannot be null.

Error message

The exception argument cannot be null.

What it means

The IntegrationExceptionEventArgs constructor requires a non-null Exception instance. If exception is null it throws ArgumentNullException parameterized with SR.WFI_NullArgument ('The {0} argument cannot be null.'). WPF-WindowsFormsIntegration uses these args to carry exceptions raised during property mapping / integration, so a null exception would make the payload meaningless.

Solutions

  1. Always pass the caught Exception (or a newly constructed Exception/InvalidOperationException describing the failure) to the constructor.
  2. If there is no real exception, use a different event-args type or construct Exception("description") rather than null.
  3. Guard the call site: if (ex != null) new IntegrationExceptionEventArgs(throwException, ex);
  4. Catch ArgumentNullException at the boundary during diagnosis to identify which integration callback passes null.

Example fix

// before
catch
{
    var args = new IntegrationExceptionEventArgs(true, null);
}
// after
catch (Exception ex)
{
    var args = new IntegrationExceptionEventArgs(true, ex);
}
Defensive patterns

Strategy: type-guard

Validate before calling

if (exception == null)
    throw new InvalidOperationException("IntegrationExceptionEventArgs requires a real Exception instance.");

var args = new IntegrationExceptionEventArgs(throwException, exception);

Type guard

static bool HasException(IntegrationExceptionEventArgs args) => args?.Exception != null;

Try / catch

try
{
    var args = new IntegrationExceptionEventArgs(throwException, ex);
}
catch (ArgumentNullException)
{
    var args = new IntegrationExceptionEventArgs(throwException, new InvalidOperationException("Unknown integration failure"));
}

Prevention

When it happens

Trigger: new IntegrationExceptionEventArgs(true, null) — typically when caller code catches without capturing the Exception object, or synthesizes 'failure' args without an actual exception.

Common situations: Custom PropertyMap translators or ElementHost/WindowsFormsHost integration callbacks constructing these event args; refactored catch blocks that lost the caught exception variable; logging paths passing null instead of a real exception.

Related errors


AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/9f75ba6e2c47c737. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/WindowsFormsIntegration/System/Windows/Integration/IntegrationExceptionEventArgs.cs:20

// The .NET Foundation licenses this file to you under the MIT license.

using System.Globalization;

namespace System.Windows.Forms.Integration
{
    /// <summary>
    /// Lets the user preview an exception before the exception is thrown.
    /// </summary>
    public class IntegrationExceptionEventArgs : EventArgs
    {
        /// <summary>
        /// Initializes a new instance of the IntegrationExceptionEventArgs class.
        /// </summary>
        public IntegrationExceptionEventArgs(bool throwException, Exception exception)
        {
            if (exception == null)
            {
                throw new ArgumentNullException(string.Format(CultureInfo.CurrentCulture, SR.WFI_NullArgument, "exception"));
            }
            _throwException = throwException;
            _exception = exception;
        }

        private bool _throwException;
        private Exception _exception;

        /// <summary>
        /// Determines whether the exception will be thrown.
        /// </summary>
        public bool ThrowException
        {
            get
            {
                return _throwException;
            }
            set

View on GitHub (pinned to 81131a70a4)