2

I'm working on creating a C# wrapper library around a native C library that allows me to directly communicate with a particular piece of hardware over a serial (COM) port.

Of course, the C library returns success/failure codes from its methods. I'd like to translate those into exceptions, but I'm having a hard time finding appropriate exceptions that are built into the .Net framework. (I try to use existing exception types whenever possible.)

Considering that this library exist to stream data from the hardware to a pc and to send commands to the hardware, I was thinking of deriving some new exception types from System.IO.IOException. This is input/output after all, but that doesn't feel very "right" considering the existing IOException types all relate to reading from files.

An example of the code I'd like to write:

if (!NativeMethods.ConnectToDevice(deviceName)
{
    var message = NativeMethods.GetLastErrorMessage();
    throw new ConnectionException(message);
}

Where ConnectionException is derived from IOException.

  • Is this a reasonable approach?
  • Am I missing some other appropriate exception either to use directly (preferred) or to derive a new type from?
2

I maintain a large collection of classes who interface and wrap around a range of hardware from bill acceptors and printers to custom circuit boards utilizing multiple communication interfaces. I think that you should pick the exception that best describes what caused an issue. For example, if the parities of the bytes didn't match up then throw a (optionally derived) System.IO exception, as it was caused by the COM Interface not the COM device. But if it was an error that the device threw, if you can know that through an API they provide, then I would make an exception class derived from Exception and throw those exceptions. In my case a bill acceptor failing it's POST is a different exception than the io message having a bad parity.

| improve this answer | |
  • That's interesting, but I think I would prefer a common inheritance hierarchy for all exceptions the library would throw. Perhaps I'm best off with a MyLibException : Exception and more specific ones deriving from that. – RubberDuck May 6 '16 at 21:56
  • I can understand why would want a common type for your wrapper. Where consumers could just catch your exception and handle appropriately. Let me ask you this, how would your consumer know that the device needs attending rather than your cable is frayed, or EMI is altering your bits on the wire. A specialized hierarchy where both exception types are derive from your exception is probably what you are looking for. – xtreampb May 6 '16 at 22:01
  • No idea to be honest... I'm really a .net developer who's learning about hardware as he goes... – RubberDuck May 6 '16 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.