1

I'm using an external SDK which wants me to use

try {
 ...
} 
catch (Ex20301Exception)
{
 ...
}

I'd rather use

try {
 ...
}
catch (CustomerOverCreditLimitException)
{
 ...
}

Is there a way I can achieve this? Or do I have to live with comments?

Mark Farmiloe
  • 396
  • 3
  • 8
  • 5
    Only if you wrap the external code, catch those exception and wrap them in your exception. – juharr Apr 13 '15 at 15:57
  • You could use an alias, although that's per module, there's no way to create per-project aliases (much less per-solution) – Jcl Apr 13 '15 at 15:59
  • 4
    While you *can* achieve this with aliases as noted in the answers, I would argue that you shouldn't and you should just use the third-party name. All this will do is confuse other developers who are expecting the third party's documented exception class. If you want to use a friendlier name (or a name specific to your domain), write a wrapper. – Ant P Apr 13 '15 at 16:01
  • Despite my comment above, I do agree with @AntP – Jcl Apr 13 '15 at 16:04
  • You could do a `Custom Exception` as per: http://blog.gurock.com/articles/creating-custom-exceptions-in-dotnet/ – Greg Apr 13 '15 at 16:10
  • The other developers may be expecting the third party to have documented the exception classes, but they haven't. The only reason I know what this exception is for, is by using Reflector. :-( – Mark Farmiloe Apr 13 '15 at 16:13
  • @MarkFarmiloe then write a wrapper around this API that exposes your own internal exceptions and use that in the rest of the solution. It is better-encapsulated, simpler and more intuitive than trying to alias the exception class. – Ant P Apr 13 '15 at 16:14
  • @AntP - I know I should, but there are at least a hundred of these 'anonymous' exceptions of which I will only need to respond to a few (I hope). And as the sole developer and the availability of F12 to track down the real (unhelpful) definitions, the alias route will suit me fine. – Mark Farmiloe Apr 13 '15 at 16:24
  • 1
    That makes using a wrapper *more* convenient, not less - your code should only have a single logical point of contact with the API anyway, so simply write an adapter for the parts of the API that your client code needs and expose that interface to the rest of your app. Then the problem goes away completely no matter how many times or in how many places you need to use the API until such a time as you need to use a *new* part of it, then all you need is a small extension to your wrapper. This promotes good encapsulation as well as being easier. – Ant P Apr 13 '15 at 16:33

2 Answers2

3

You can create an Alias

using CustomerOverCreditLimitException = External.NameSpace.Ex20301Exception;
Ortiga
  • 8,455
  • 5
  • 42
  • 71
  • @AntP I'd agree if it was a hard to see global configuration. Since it must be declared on top of the file, it causes much less damage. If well used, it can actually make the code easier to understand. – Ortiga Apr 13 '15 at 16:07
  • 1
    I couldn't disagree more, I'm afraid. I'm not in the habit of actively reading using directives (and neither is anyone else) and having to deduce that there's an alias on a particular class is nothing but an unnecessary obstacle to a developer. It also doesn't solve the problem for developers handling the exception in other/new places. Aliases should be reserved for resolving ambiguities for the compiler - for exposing domain-specific/internal naming, *abstraction* (e.g. a wrapper/adapter) is more intuitive and offers better encapsulation. – Ant P Apr 13 '15 at 16:12
2

Possible duplicate of How do I alias a class name in C#?

In the usings...

using CustomerOverCreditLimitException = The.Fully.Qualified.Namespace.Ex20301Exception;
Community
  • 1
  • 1
Ashley Frieze
  • 4,993
  • 2
  • 29
  • 23
  • Is it possible to make this alias the only option? I want to restrict using The.Fully.Qualified.Namespace.Ex20301Exception in my project. – Akmal Salikhov Jun 20 '23 at 08:40