Allow 'None' error type

[pdeva]

this allows for code paths that are like:

let error = if auth_succeeded()  { 
 ResponseError::None 
} else  {
  ResponseError::InvalidMsg
};


ResponseBuilder::default().with_error_code(error.code());

[tychedelia]

This is failing because try_from_code (and possibly other paths) expect to return a Option<ResponseError> where None represents error code 0. I'm amenable to changing this to support your use case, but we'll have to figure out how to modify the existing error macro. Please look at it's implementation for more details.

[rukai]

I think we should continue to represent no error as Option::None.
At least on the receiving side it is easier to work with.

I do see that the logic you need is a bit verbose to express currently.
The best we can do with the current state of things is:

let error = if auth_succeeded()  { 
  None
} else  {
  Some(ResponseError::InvalidMsg)
};


ResponseBuilder::default().with_error_code(error.map(|x| x.code()).unwrap_or_default());

But maybe we could change the with_error_code definition to:

    pub fn with_error_code(mut self, value: Option<ResponseError>) -> Self {

Then we could use it like:

let error = if auth_succeeded()  { 
  None
} else  {
  Some(ResponseError::InvalidMsg)
};


ResponseBuilder::default().with_error_code(error);

Does that sufficiently improve the ergonomics?

[tychedelia]

I agree that keeping the ergonomics for receiving is important.

[pdeva]

i think adding the use of Option is so redundant when the base error type already contains a None value. its less verbose everywhere and just overall feels simpler to use.

[tychedelia]

This could potentially be changed to return an error in the case of unknown rather than having the catch all enum branch. In either case, the current method is now infallible so the try naming and option return type doesn't make sense.