Question

I am writing a custom .Net SDK for the mapping program MapInfo Pro, mapinfo only exposes two methods to use over COM void Do(string cmd) and string Eval(string cmd). When you use one of these methods and you do something invaild, it returns a a COMException with a error message and I get the error code from MapInfo. So for example an error message looks like this:

 418  "Table not found."

Now I would like to throw some kind of meaning full exception rather then just a exception with a number and message that people have to catch then use a if block to check what error, something they say they only want to catch and do something meaning full with. Something like TableNotFoundException.

The biggest problem is there are currently 1999 possible error messages, now I don’t want a exception class for everyone of those errors.

The idea of the SDK is that people use my objects and methods rather then Do and Eval(they can stil use them if they want).

Should I,

• everywhere in my SDK that I call Do and Eval use a try catch and then check the error code and throw something more meaning full from there, because I know what errors I should get.

or

• I have somekind of God lookup list in the Do and Eval that when a COMException is thrown it lookups the error code and throws the meaningfull error from there? Meaning I don’t have to wrap every call to Do and Eval in try catch blocks(there are a lot of calls)

Bit of a tricky thing to explain so I hope people can understand it.

Thanks.

Answer 1

Wrap the calls to Do and Eval in your own function which catches MapInfo errors.

As there are so many error types, you could create an enum with some more descriptive names or a dictionary mapping error numbers to more friendly names (if the original ones aren’t good enough) – you don’t want 1999 exception classes, so I’d suggest using only one exception class that contains the error number and description. You’re saying that users could use Do and Eval directly, so they should know how to handle these error numbers, anyway.

Alternatively, you could create a few hierarchical exception types and decide which one to throw (needs something a dictionary mapping 0-1999 => matching exception type) – that way, users can be a bit more specific about which types of errors to catch.