CODEWITHSUNDEEP
c#.netexception.net-core.net-standard
Matteo Mosca
Matteo Mosca

Reputation: 7448

C#, usage of custom exceptions

I need to make a short premise: I am a software architect with more than 20 years of experience, not a junior asking directions. This is not to say "I know it all" (quite the contrary in fact) but just to give context and state that I have come across a legitimate doubt about something I thought was common knowledge and best practice and have done so for all this time.

I am working on different projects for different clients. I always check method's parameters for not being null and for other non valid states. A common precondition check you can find in my code is:

if (param == null) { throw new ArgumentNullException(nameof(param)); }

or

this.myField = myParam ?? throw new ArgumentNullException(nameof(myParam));

Also bear in mind that I use exceptions sparingly, I do not do user input validation with exceptions, I just use them to check and/or signal invalid states in the code, thus programming errors. It's extremely rare to find a try/catch block in my code at all.

One of my clients just asked me, without much margin to debate, to replace any similar occurrence with the use of custom exceptions. Meaning I am to define a CustomerNameArgumentNullException, CustomerNameFileNotFoundException, etc. and use those wherever I would use a standard exception.

Now I will comply, I have no right to debate the client request, but their lead programmer was pretty strong about this point on how this is the right way to go, that using default exceptions makes code less readable and also that custom exceptions make more easy to see what-is-what in Azure Application Insights. I tried to point out that he has the fully qualified name of the method that raised the exception so he can know which program, in which assembly and namespace and such but again, there was not much room to debate and it was not my place to do so.

So I've been wondering if he's actually right and I've been doing exceptions wrong all this time. If anyone has some more insight and/or some material I can read about that supports this theory.

Thanks.

Upvotes: 6

Views: 1616

Answers (2)

Jon Skeet
Jon Skeet

Reputation: 1500465

While normally I'd suggest that a question like this should be closed as opinion-based, in this case there's really clear guidance from Microsoft:

Use the predefined .NET exception types

Introduce a new exception class only when a predefined one doesn't apply. For example:

  • Throw an InvalidOperationException exception if a property set or method call is not appropriate given the object's current state.

  • Throw an ArgumentException exception or one of the predefined classes that derive from ArgumentException if invalid parameters are passed.

In other words, your customer is asking you to go against guidance from the platform authors.

You may not be able to change the customer's mind to follow the guidance, but you can be confident that your approach is the recommended one, and their approach goes against that.

Following conventions like this is particularly important in Open Source projects - it's one thing to decide that you'll have your own conventions when only your team will work with the code, but if an application uses 10 different Open Source libraries, each of which has decided to create its own conventions, that's a nightmare.

Upvotes: 9

Teja
Teja

Reputation: 325

There are two sides of the coin. Sure MS recommends this

Using custom exceptions gives you some advantages and disadvantages.

Advantages:

  1. Abstraction
  2. You can log telemetry data before you raise an exception. If not for custom exceptions, you'd have to catch an exception, log data and re-throw.
  3. Customizing exception and error handling as needed by the app/services, etc

Disadvantages:

  1. Telemetry data will have no stack trace if you are throwing custom exceptions.
  2. Code maintenance and rigorous testing

There are various other things that come into picture, but catching an exception, logging metrics and then re-throwing (to preserve stack trace) the same exception is expensive.

Just my thoughts.

Upvotes: 1

Related Questions