Optional custom error for constraints?

[fanatid]

Sometimes it's can be useful to have a special error code for constraints because this can provide a clear error message. Possible syntax:

#[account(constraint = <expression> ? MyError)]

Maybe not limited by constraint only?

[armaniferrante]

Agreed. I think this would be useful for any constraint, particularly those where there can be more than one, e.g., has_one, so that one can differentiate between the scenarios.

I like the ?. Another possibility would be to use a ;.

#[account(constraint = <expression>; MyError)]

Though I don't have a preference. Tag @Henry-E who I previously discussed this with as well.

[fanatid]

In the case of ; how few constraints will look like?

#[account(
  constraint = <expression>; MyError,
  constraint = <expression>
)]

vs

#[account(
  constraint = <expression> ? MyError,
  constraint = <expression>
)]

but in general, I do not care about symbols if a custom error will be possible.

[armaniferrante]

Another one that I like in addition to ? is

#[account(
    constraint = <expression> ! MyError,
    constraint = <expression>
)]

[acamill]

Was hoping for this. Voting for ! as it implies unwrapping/error, ? implies conditional (to me, coming from Swift).

Or possible to have something rustier like : Constraint = (condition).map_err(Error)? Not very rust savvy

[Henry-E]

Not sure but there might be better error logging in general coming soon which solves this problem without needing extra syntax

On Thu, Oct 7, 2021, 4:49 AM acamill @.***> wrote:

Was hoping for this. Voting for ! as it implies unwrapping/error, ? implies conditional (to me, coming from Swift).

Or possible to have something rustier like : Constraint = (condition).map_err(Error)? Not very rust savvy

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/project-serum/anchor/issues/509#issuecomment-937420443, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAHMGGMZZ2XVOGUNJQKAJDUFUKE5ANCNFSM5AEHSIKQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[armaniferrante]

The custom error would be nice for GUIs perhaps.

[acamill]

The custom error would be nice for GUIs perhaps.

Even for debugging constraintful contextes. Currently offloading so pre checks in "access-control" even if it's not acl related

[rav3nh0lm]

Yes would be amazing, I am trying to debug some code, and it's incredibly exhausting trying to understand where the error originated from (i.e. from one of the macros)

[acamill]

I am currently dodging this by using access_control even if it's not really about rights. Doing some pre check there (most of the constraints that are a bit freestyle) so that I can have custom errors.

Would it make sense for clarity sake to have another function similar to access_control but named something like parameter_validation, or that should just be in the main body of the IX code (I like to have purely the execution logic there)?

Long term most of the arbitrary constraints should be about mint/authority, all these field related to the underlaying "native" types. For the custom stuff it might make more sense to be offloaded somewhere else as in these "parameter_validation" that are purely business logic.

[armaniferrante]

Closed by #905.