You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when wanting to run a compilation or execute a program without waiting for everything to be completed, the flag --abort-on-first-error or --no-recover can be specified. Both though have practically the same functionality and therefore don't change much for the user.
The current problem with --abort-on-first-error stems from the underlying compiler configuration CompileConfig.abortOnFirstError, which is directly bound to the flag of the CLI. This causes the compiler to throw an actual KipperError instance, which has to be accounted for in the CLI implementation.
As that introduces multiple edge cases it seems to make a lot more sense to entirely remove it in favor of --no-recover, as that also provides a clear distinction between recovering from errors and attempting to get all possible errors i.e. --recover and instantly aborting on the first error encountered i.e. --no-recover.
Note
With the next release 0.10.4 that fixes #491, --abort-on-first-error will be deprecated and marked for removal in 0.11.0.
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Current State & Issue
Currently when wanting to run a compilation or execute a program without waiting for everything to be completed, the flag
--abort-on-first-error
or--no-recover
can be specified. Both though have practically the same functionality and therefore don't change much for the user.The current problem with
--abort-on-first-error
stems from the underlying compiler configurationCompileConfig.abortOnFirstError
, which is directly bound to the flag of the CLI. This causes the compiler to throw an actualKipperError
instance, which has to be accounted for in the CLI implementation.As that introduces multiple edge cases it seems to make a lot more sense to entirely remove it in favor of
--no-recover
, as that also provides a clear distinction between recovering from errors and attempting to get all possible errors i.e.--recover
and instantly aborting on the first error encountered i.e.--no-recover
.Note
With the next release
0.10.4
that fixes #491,--abort-on-first-error
will be deprecated and marked for removal in0.11.0
.The text was updated successfully, but these errors were encountered: