"The Colonial" was trawling through some code they inherited, and found this approach to doing exceptions in C#:
public enum ReturnCode : int
{
Success = 0,
Enum1 = 100,
Enum2 = 110,
// *snip* - LOTS of enums
// .
// .
UnknownError = 998,
Exception = 999
};
Whitespace in the original.
So, instead of using structured exception handling, we return enums from functions to represent our status codes. This almost makes me assume that this is a case of a C programmer reluctantly using C#. "Who even needs exceptions anyway? I've been returning status codes and putting an onion on my belt, which was the style at the time."
But it actually gets worse than this.
public static string ErrorDescr( ReturnCode errorNum )
{
string descr = "";
int errNum = (int)errorNum;
switch (errNum)
{
case 0: descr = "Success"; break;
case 1 : descr = "Message 1"; break;
case 2 : descr = "Message 2"; break;
case 3 : descr = "Message 3"; break;
// *snip* - LOTS of cases
// .
// .
case 998: descr = "Unknown Error"; break;
case 999: descr = "Exception"; break;
}
return descr;
}
This converts the enum back into an integer, so that we can have a massive case statement that converts the integer into a string. The entire point of using an enum would be to ensure that you never have to use bare magic numbers, and yet, here we are- undoing the work of the enum so that we can do everything wrong.
And, of course, this is the error handling system that touches every part of the code. You can't simply pick this out easily and replace it with structured exception handling. The entire calling convention is built to assume ReturnCode
s coming back from every function.