Improvement: add args to "Fail" handler

[bibolorean]

Currently one can't access the original supplied arguments in a fail handler.
But especially if you want to modify the exception to contain some more information (related to arguments) it would be very nice to have access on those.

In my environment, we are using your library to add operational tracing and an exception re-writer extension to File & Directory. So whenever a call to one of those fails, we create a new Exception containing the "path" tried to access (to improve the logs. E.g. tell the Sysadmin: 'Hey, access on blabla failed because of UnauthorizedAccessException')..

[ursenzler]

@danielmarbach is there an easy way to add the arguments?

Or would we have to add them all manually :-O ?

Or do you see a problem passing the original arguments to the Fail methods?

[danielmarbach]

You have to add them manually.

You mean apart from introducing breaking changes ;) no there shouldn't be any issues. You have the arguments all available. You just need to update the convention based invocation magic ;)

[bibolorean]

I would have tried it on my fork.. but I didn't find the "text templating magic test" which would generate the wrappers with the new API.. ;-P

[danielmarbach]

I think I deleted that one after it served its purpose

[ursenzler]

Okay, I'll add the original arguments to the Fail* methods.

But it will take some time... (2 month or so due to little spare time ahead)

If you need a quick solution, let me know. We could arrange paid support probably.

[bibolorean]

As it does also work with the TLS keeping the path - for the moment that's fine for me. But I still would love to see that change - then I could get rid of the variable keeping the path :)

[ursenzler]

This is implemented, but not yet merged. Appccelerate.IO 2.42.0-commitc61a1f4b on MyGet contains the changes.