System.ApplicationException
ApplicationException is a base class that was meant for exceptions thrown by applications, as opposed to the ones thrown by the runtime. It was a design idea from the first versions of .NET that did not turn out useful, and the guidance today is not to use it.
You see it in older code bases where custom exceptions derive from it, and in logs from those. It behaves like any other exception, so catching and handling it is not different.
Minimum version: >= 1.1 >= Core 2.0
Statistics
18
Common causes
There is no failure behind an ApplicationException. It is the type that someone chose when they wrote the exception class. Typical cases:
A custom exception that derives from it
Early .NET documentation and many books told developers to derive custom exceptions from ApplicationException. The result is a hierarchy that has an extra level with no benefit, because nobody catches ApplicationException on purpose.
public class PaymentException : ApplicationException
{
public PaymentException(string message) : base(message) { }
}Derive from Exception instead. It changes nothing for callers that catch the specific type:
public class PaymentException : Exception
{
public PaymentException(string message) : base(message) { }
public PaymentException(string message, Exception inner) : base(message, inner) { }
}Code that throws it directly
Throwing ApplicationException without a custom type is the same as throwing Exception. It says that something failed in the application, which every exception does.
public void Charge(decimal amount)
{
throw new ApplicationException("The card was declined");
}Throw a specific exception type, or a custom one that describes the failure:
public void Charge(decimal amount)
{
throw new InvalidOperationException("The card was declined");
}Catching it to catch every error in the application
Some code catches ApplicationException and expects it to cover all exceptions from the application. Only the ones that derive from it are caught, and exceptions from the framework are not.
Catch the specific types that you know, or Exception where you need a catch-all.
How to fix it and prevent it
Derive custom exceptions from Exception
Give the type the usual constructors, and add properties for the data that a handler needs. Name it with the suffix Exception.
public class OutOfStockException : Exception
{
public OutOfStockException(string sku) : base($"Product {sku} is out of stock")
{
Sku = sku;
}
public string Sku { get; }
}Use a built-in type when one fits
You often do not need a custom type. InvalidOperationException, ArgumentException and NotSupportedException already describe the most common problems.
Migrate old hierarchies one type at a time
Change the base class of the custom exceptions and fix the catch blocks that mention ApplicationException. A search for the type name finds both. Exceptions that cross a serialization boundary can need a check of their serialization code.
How to read the stack trace
It reads like any other exception. The type name shows which custom class was thrown:
Shop.Services.PaymentException: The card was declined
at Shop.Services.PaymentService.Charge(Decimal amount) in C:\src\Shop\Services\PaymentService.cs:line 15
at Program.<Main>$(String[] args) in C:\src\Shop\Program.cs:line 4The type is Shop.Services.PaymentException, and it was thrown on line 15 of PaymentService.cs. Whether the class derives from ApplicationException does not show in the trace, so search for the class to see its base type.
Should you catch it?
Catch the custom type, not ApplicationException. Catching the base class only catches exceptions that derive from it, so the code looks like it handles every application error and does not.
If you must catch it to support old code, catch it together with the specific types, and plan the migration.
Find ApplicationException before your users do
elmah.io logs every unhandled exception in your .NET application with its stack trace and request details, groups identical errors and notifies you when a new one appears.
Start free trialRelated exceptions
- Exception is the base class that custom exceptions should derive from.
- NotSupportedException is a good choice when an operation is not available on a type.
- ArgumentException is for arguments that are not valid.
Frequently asked questions
Is ApplicationException obsolete?
It is not marked with the Obsolete attribute, but the documentation says that you should not throw it or derive from it. Derive from Exception instead.
Why did Microsoft recommend it in the beginning?
The idea was to separate exceptions of the runtime, which derive from SystemException, from the ones of applications. The framework itself did not follow it, so the split became meaningless.
Does changing the base class break my code?
Only code that catches ApplicationException to handle your exceptions. Code that catches the specific type or Exception works the same.
Does the .NET Framework throw ApplicationException?
Almost never. A few old types in the framework and some third-party libraries do, so a plain one in a log points to code that is old.
Let your AI agent track it down
Connect Claude Code, Cursor, VS Code or Visual Studio to the elmah.io MCP server and ask your agent to look into ApplicationException for you. For example:
The agent reads the stack trace and request details from elmah.io, finds the code in your repository and proposes a fix. In Claude Code, add the server with one command:
claude mcp add --transport http --client-id claudecode elmahio https://mcp.elmah.io/mcpThe MCP server is included on every plan and is currently in beta. Set up the MCP server.
Further reading
YouTube videos
Answers from Stack Overflow
In the C# IDE, type 'exception' and hit TAB. This will expand to get you started in writing a new exception type. There are comments withs links to some discussion of exception practices.
Personally, I'm a big fan of creating lots of small classes, at that extends to exception types. For example, in writing the Foo class, I can choose between:
throw new Exception("Bar happened in Foo");throw new FooException("Bar happened");throw new FooBarException();
where
class FooException : Exception
{
public FooException(string message) ...
}
and
class FooBarException : FooException
{
public FooBarException()
: base ("Bar happened")
{
}
}
I prefer the 3rd option, because I see it as being an OO solution.
By Jay Bazuzi. Read the original answer on Stack Overflow.
Inherit from System.Exception. System.ApplicationException is useless and the design guidelines say "Do not throw or derive from System.ApplicationException."
See http://blogs.msdn.com/kcwalina/archive/2006/06/23/644822.aspx
By Mark Cidade. Read the original answer on Stack Overflow.
You are not handling the case whereby the mutex.WaitOne returns false ie times out. If WaitOne returns false you don't own the mutex therefore you don't need to release it.
bool iOwnTheMutex;
try {
// set up mutex here...
iOwnTheMutex = mutex.WaitOne(2000);
if (iOwnTheMutex) {
// do what you need to do
}
}
finally {
if (mutex != null && iOwnTheMutex) {
mutex.ReleaseMutex();
}
}
By Jack Hughes. Read the original answer on Stack Overflow.
You have to be careful when comparing date times because it may seem like they are the same but they can vary down to the ticks (100 nanoseconds). It's probably failing because sql server doesn't store the date times that accurately.
You'll need use a custom equality comparer such that you only compare year, month, day, hour, minute and second probably.
Take a look at this article too: Why datetime cannot compare?
By Cole W. Read the original answer on Stack Overflow.
The base exception from where all other exceptions inherit from is System.Exception, and that is what you should inherit, unless of course you have a use for things like, say, default messages of a more specific exception.
By Jon Limjap. Read the original answer on Stack Overflow.
Source: Stack Overflow