Fix panic on mismatching request/response function codes

[uklotzde]

Fixes #252.

[uklotzde]

The seconds commit introduces another error variant that replaces std::io::Error in case of mismatching headers between request and response. All error variants include the actual response result.

[flosse]

I'm sorry, where exactly is the fix?

[uklotzde]

The fix (RTU).

[uklotzde]

The fix (TCP).

[uklotzde]

I am still unsure if it would be more suitable to replace the outer std::io::Error with a new error type or the inner type as done here. Where do protocol errors belong?

[uklotzde]

The alternative approach of replacing the outer std::io::error with a custom error type and preserving Exception as the inner error type turned out to be much more elegant.

The different sources of errors are now separated more consistently, i.e. client/server communication vs. server-side processing.

[flosse]

I am still unsure if it would be more suitable to replace the outer std::io::Error with a new error type or the inner type as done here. Where do protocol errors belong?

In general I'd look on the layers.

Application -> Modbus -> Transport

So my error design would be

enum MyAppError {
  Modbus(ModbusError),
  // other app specific
}
enum ModbusError {
  Transport(TransportError).
  // other modbus specific
}
enum TransportError {
  // ...
}

So the top level error in this library would be a very specific error where io::Error is just one variant.

[flosse]

The alternative approach of replacing the outer std::io::error with a custom error type and preserving Exception as the inner error type turned out to be much more elegant.

😂 it looks like you had the same idea 😄

💯

[uklotzde]

Keeping the Exception separate as a not-really-an-error without wrapping it justifies the nested Result pattern.