The pull request simplifies the error handling of various functions and methods in the FsAutoComplete project by using option and asyncOption types instead of Result and ResultOrString types. This avoids unnecessary wrapping and unwrapping of results and allows returning more informative error messages. The pull request affects the files src/FsAutoComplete.Core/Commands.fs, src/FsAutoComplete/LspServers/AdaptiveFSharpLspServer.fs, src/FsAutoComplete/LspServers/AdaptiveServerState.fs, src/FsAutoComplete/CodeFixes.fs, src/FsAutoComplete/CodeFixes.fsi, and several files in the src/FsAutoComplete/CodeFixes folder.
We're sailing on the asyncOption tideWe've left the Result types behindWe'll heave away and simplify the codeAnd make the error messages more kind
📄🛠️🚀
WHY
This function was being used as a Result type and often times being converted to an option type. Since the function either was opened or it wasn't, I felt this refactor expresses the intent more clearly. It think it also allows the higher order functions to "think" more on what better error messages could be, rather than passing the "could not read file" up the pipeline.
Change the type of the tryGetFileCheckerOptionsWithLines parameter from a function that returns an Async<Result<IFSACSourceText, _>> to a function that returns an Async<IFSACSourceText option> in the Commands module, and handle the case where the function returns None by returning an error message with the file name (link, link, link, link, link)
Change the type of the tryGetFileSource parameter from a function that returns an Async<ResultOrString<IFSACSourceText>> to a function that returns an Async<IFSACSourceText option> in the Commands module, and handle the case where the function returns None by returning an error message with the file name and a flag to indicate whether the error should be fatal or not (link, link, link)
Change the type of the GetFileLines alias from a function that returns an Async<ResultOrString<IFSACSourceText>> to a function that returns an Async<IFSACSourceText option> in the CodeFixes module, and handle the case where the function returns None by returning an error message with the file name in the code fixes (link, link, link, link, link, link, link, link)
Change the name of the forceFindOpenFileOrRead function to tryForceFindOpenFileOrRead in the AdaptiveServerState module, and handle the case where the function returns None by returning an error message with the file name or using the asyncOption workflow (link, link, link, link, link, link, link, link, link)
Change the return type of the GetOpenFileOrRead method from Async<Result<VolatileFile, string>> to Async<VolatileFile option> in the AdaptiveServerState module, and handle the case where the method returns None by returning an error message with the file name or using the asyncOption workflow (link, link, link, link, link, link, link, link, link, link)
Note
I also updated FsToolkit.ErrorHandling to the latest version
WHAT
🤖[deprecated] Generated by Copilot at 5501b05
The pull request simplifies the error handling of various functions and methods in the FsAutoComplete project by using
optionandasyncOptiontypes instead ofResultandResultOrStringtypes. This avoids unnecessary wrapping and unwrapping of results and allows returning more informative error messages. The pull request affects the filessrc/FsAutoComplete.Core/Commands.fs,src/FsAutoComplete/LspServers/AdaptiveFSharpLspServer.fs,src/FsAutoComplete/LspServers/AdaptiveServerState.fs,src/FsAutoComplete/CodeFixes.fs,src/FsAutoComplete/CodeFixes.fsi, and several files in thesrc/FsAutoComplete/CodeFixesfolder.🤖[deprecated] Generated by Copilot at 5501b05
📄🛠️🚀
WHY
This function was being used as a Result type and often times being converted to an option type. Since the function either was opened or it wasn't, I felt this refactor expresses the intent more clearly. It think it also allows the higher order functions to "think" more on what better error messages could be, rather than passing the "could not read file" up the pipeline.
HOW
🤖[deprecated] Generated by Copilot at 5501b05
Resultoroptiontypes by using theasyncResultOptionworkflow in theAdaptiveFSharpLspServermodule (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)tryGetFileCheckerOptionsWithLinesparameter from a function that returns anAsync<Result<IFSACSourceText, _>>to a function that returns anAsync<IFSACSourceText option>in theCommandsmodule, and handle the case where the function returnsNoneby returning an error message with the file name (link, link, link, link, link)tryGetFileSourceparameter from a function that returns anAsync<ResultOrString<IFSACSourceText>>to a function that returns anAsync<IFSACSourceText option>in theCommandsmodule, and handle the case where the function returnsNoneby returning an error message with the file name and a flag to indicate whether the error should be fatal or not (link, link, link)GetFileLinesalias from a function that returns anAsync<ResultOrString<IFSACSourceText>>to a function that returns anAsync<IFSACSourceText option>in theCodeFixesmodule, and handle the case where the function returnsNoneby returning an error message with the file name in the code fixes (link, link, link, link, link, link, link, link)forceFindOpenFileOrReadfunction totryForceFindOpenFileOrReadin theAdaptiveServerStatemodule, and handle the case where the function returnsNoneby returning an error message with the file name or using theasyncOptionworkflow (link, link, link, link, link, link, link, link, link)GetOpenFileOrReadmethod fromAsync<Result<VolatileFile, string>>toAsync<VolatileFile option>in theAdaptiveServerStatemodule, and handle the case where the method returnsNoneby returning an error message with the file name or using theasyncOptionworkflow (link, link, link, link, link, link, link, link, link, link)Note
I also updated FsToolkit.ErrorHandling to the latest version