https://github.com/pantsbuild/pants/pull/10954 this allows try/except across an

await Get(...)

, which allows `@rule`s to raise exceptions without necessarily making pants exit immediately. i think this will be very useful for plugin authors, but it is easy to wait if we'd prefer to get 2.0 out the door first

there’s a release branch for 2.0.0 now so

master

changes shouldn’t need to wait

thanks!

exciting change, I'll definitely take a look at this soon

:D :D :D

This overall looks really exciting! Iirc, there was some discussion a while ago about the value of adding exception handling to rules because we generally want to discourage that style and encourage more FP-style of using the type system to express failure, like

Optional

. But also Python != Rust (e.g. no

Result

type), and it’s likely very valuable to have the mechanism, even if we discourage it.

yes that was my concern

yeah that's a fair point

i was thinking this would be more familiar to python users and possibly improve the learning curve / make it easier to take advantage of 3rdparty python libraries that use exceptions when writing plugins. i think if python had rust enums i would not have proposed it, but as is, that pattern would require 3 separate dataclass definitions i think

I haven’t had the time to look closely yet, so sorry if this is already answered, but one main question I have is if it’s possible to do exception handling for Rust failures. That might be really powerful to catch a failure for

MergeDigests

, for example. If anything, it would allow us to write much better error messages. (For example, it’s possible with the

output_path

field for the user to introduce conflicting paths from different assets. It would be AWESOME if we could

try except

that one

await Get

, and print a custom error message upon failure.) A big issue with error messages in the engine right now is that they have to be hyper generic, so they often miss valuable context

yes! that should work. i can write a test for it

I think if we can use this feature to implement better error messages today in pants, that justifies it

i had totally missed how useful the intrinsic error handling could be

It’d be excellent to add that as a major motivation in the PR description. And maybe proactively acknowledge the concerns about exception handling in general - we won’t liberally encourage the style, but there are a couple niche cases where it’s extremely valuable

will do!

btw I just created https://github.com/pantsbuild/pants/pull/10955, which has (I think) the last round I'm gonna do of converting python API functions to use

PyObject

instead of

Value

. not sure to what extent this is going to interfere with your code in this PR @chilly-magazine-21545

thank you for noting that! the only place we access attributes in the try/except PR is when extracting the exception traceback, which actually uses explicit hasattr/getattr. in fact i'd like your feedback on that whenever you get the chance to look at this because i'm not sure if i'm doing something wonky, i'll leave a comment in the section i'd like a look at

sure. I'm gonna sign off for tonight but I'll take another look at this tomorrow

thanks! i'll take a look at yours too

@chilly-magazine-21545 I left some comments on https://github.com/pantsbuild/pants/pull/10954, overall I think the approach is pretty solid, and most of my comments have been basically ways I noticed that the code in this PR could be more concise in any given spot