tryEval: catch all EvalError exceptions

[DavHau]

Aside from throw and assert, tryEval will now also catch other eval errors like type errors, abort and JSON parse errors.
This gives the user the capability to write code that is able to recover from common evaluation errors.
Examples:

• Before this change, it was hard to detect if a given string is valid JSON. This can be useful for lock file parsing
• An error in nixpkgs' lib.toInt was not recoverable as this is also based on json parsing.

fixes #5455

related: #356

[xaverdh]

Independent of this change, maybe another builtin with more fine grained control would be a good idea?
So you could explicitly say what errors you (don't) want to catch?

[DavHau]

Independent of this change, maybe another builtin with more fine grained control would be a good idea? So you could explicitly say what errors you (don't) want to catch?

Another possible solution for this which has been proposed in some other issue is to return the error itself inside the return value.
That gives you the capability to treat individual errors differently.

But this should probably be discussed elsewhere.

[edolstra]

No, we shouldn't do this. tryEval has always been a bad idea and we should not expand its use, since exception handing is not really compatible with a lazy functional language. So it's intentionally restricted to assertions only. tryEval was really only ever intended to allow Nixpkgs' release.nix to traverse pkgs, which requires being able to catch assertions. So if it starts catching stuff like type errors, it masks actual bugs. The solution to type errors is to fix them, not catch them.

In particular, aborts should not be caught. The whole point of abort is that it isn't caught.

[edolstra]

Another possible solution for this which has been proposed in some other issue is to return the error itself inside the return value.

tryEval intentionally does not return the error, because that would make the result of tryEval depend on the evaluation order. (E.g. in tryEval (a + b) it's not specified whether a or b is evaluated first, so if they both throw different errors, the result of this expression would be unspecified.)

[DavHau]

Thanks for clarification. Closing

[adrian-gierakowski]

how could I customise error message thrown by builtins.fromJSON then?

[de11n]

Something like this would still be useful, however, for Nix tooling. nix-eval-jobs still cannot handle an input that has type errors or even something as common as a derivation function expecting an argument attribute that is no longer available. The only option at this point is to write a custom evaluator.