Am 11.11.2016 um 22:37 schrieb Niall Douglas:
On 11 Nov 2016 at 21:23, Klemens Morgenstern wrote:
an explanation and a sort of tutorial explaining the history and purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd greatly appreciate if people could tell me:
1. Does it make sense? Yes, it does. Especially for embedded development, this seems very useful. Oh great. Thank you. I was worried it was too long and/or boring and/or confusing. I am familiar with the problem, because I'm actually planning to work on an stm32 periph-library, for which I need a solution for that exact problem.
I just had another idea (I hope I didn't miss that): it would be awesome if there was some way to deal with objects, that might have an errornous state. I.e. something like that: outcome<path> p1("-invälid#value"); //error set outcome<path> p2("valid-value"); //not set int i = p2->something_errornous(); //now I have a set error. I'm not sure how to do that, but maybe something like this: the ctor checks through std::is_nothrow_constructible if the last argument can be std::error_code or something like that and then takes this one to capture the error; elsewise it catches the exception. And for the member-functions you could use some indirect call, like this: p2.invoke(&path::something_errornous); Which then calls the matching function with an std::error_code or the exception. I'm not sure if that should return outcome<int> or int and put the error into p2. This would be useful for a library, which uses the std::error_code or exception pattern, because it could be integrated with your library very convienently.
Is there a way to switch the behaviour depending on whether exceptions are available? I.e. throw if they are, elsewise use the result? Or would you consider this a horrible Idea? Already present. All exceptions are thrown via a user redefinable macro. Each individual throw gets its own macro. When exceptions are disabled in the compiler, the default implementation dumps a stacktrace and terminates the process, but user code can do anything else it feels like.
I would add that it should be the case that if properly used Outcome never throws an exception, not ever. Therefore it should never terminate the process.
One thing I'll add before peer review is an optional facility that it will cause a link error if your code ever could cause an exception to throw. This should aid debugging. Intersting, how would that work? And if I disable exceptions (-fno-exceptions) I'd already get an error.
The reason for me would be, that I could write a library which's user could use it both ways, depending on what he has available. I think if I wanted to provide a way to have a function-call using an exception or an error_code, I'd go with the C++11 way, i.e. distinguish this in the signature. So for me the main use-case would be, that exceptions might not be available. This is major use case intention for Outcome and exactly what I use it for myself.
Thanks for the feedback Klemens.
Niall