Retrieve errors when exitOnError is set to false

[SamVerschueren]

From @okonet

I've just tried to integrate it and can't wrap my head on how do I display all errors when all tasks complete. When using default renderer, it just continues silently now, so I was expecting the error argumemt in the catch to contain all my errors. Looking at the code it is not the case. Is there a way of accessing it somehow after the execution? Should it be some internal state I have to take care of? Please point me in the right direction.

Because exitOnError is set to false, at the end, the .catch function is not being invoked and you end up in then. Because the result of the promise is the context object, we could add an errors array and push all the errors into that list. A downside of this approach though is that we should make it a read-only property so that people can't overwrite that property.

@okonet @frederickfogerty thoughts?

[okonet]

The problem with then is that I don't have access to ctx in it anymore. At least it looks like no arguments is being passed there and this is also referring to undefined.

I think having all errors in one place and still be able to catch them would be a great help for such use cases. But I'm okay with implementing it myself as well. But it seems the current API doesn't really allow this.

[SamVerschueren]

Yes, then should return the context. See also this test.

[SamVerschueren]

@okonet So from what I understand is that you want the main process to throw after all the tasks have executed so you would end up in the catch?

[okonet]

Yeah, I think that would be the appropriate behavior for it.

[SamVerschueren]

Yeah, that actually makes sense. Just wondering what I should throw though. A custom error object and attach the error list.

const err = new ListrError('Some tasks might have failed');
err.errors = errorList;

throw err;

[okonet]

That makes sense to me. The err.errors can be then accessed in catch(err) block, right?

[SamVerschueren]

Yes exactly.

[SamVerschueren]

And maybe it makes sense to also attach the context to the error so you can access that one via err.context. Otherwise it would not be possible to do that.

[okonet]

Yes, it totally makes sense!

[frederickfogerty]

Looks good to me 👍

[SamVerschueren]

Released in 0.11.0. Sorry for the late response, was quite busy.

[okonet]

Awesome! Thanks for the work. I'm integrating it now.

[SamVerschueren]

Let me know how it went !

[okonet]

Worked like a breeze: lint-staged/lint-staged#131. Thanks again for your work!