search for: creatbinari

Yes definitely, testing a small piece of code like the GlobPattern::create() example, it would mostly indicate missing unit tests or insufficient test data. In contrast to unit tests, however, it can also verify correct handling of errors passed between function call hierarchies in more complex scenarios. For this I should point to the other example in the code, where it's applied to

Hi Stefan, David, This is very interesting stuff - it adds a dimension of error security that Error/Expected can't provide on their own. I think it would be interesting to try to build a tool around this. Did you identify many cases where "real work" (in your example, the nullptr dereference" was being done in an error branch? My suspicion is that that should be rare, but that

On Mon, Jul 31, 2017 at 8:19 AM Stefan Gränitz <stefan.graenitz at gmail.com> wrote: > Hi Lang, hi David, thanks for looking into this. > > > > Did you identify many cases where "real work" (in your example, the > nullptr dereference" was being done in an error branch? > > In my own code yes, not in LLVM ;) I'd like to run it on a large example,

Hello, this is a call for feedback: opinions, improvements, testers.. I use the support classes Expected<T> and ErrorOr<T> quite often recently and I like the concept a lot! Thanks Lang btw! However, from time to time I found issues in the execution paths of my error cases and got annoyed by their naturally low test coverage. So I started sketching a test that runs all error paths