Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add assert_with_error! macro #749

Merged
merged 5 commits into from
Nov 2, 2022
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 24 additions & 1 deletion soroban-sdk/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,30 @@ pub use soroban_sdk_macros::symbol;
macro_rules! panic_error {
($env:expr, $error:expr) => {{
$env.panic_error($error);
unreachable!()
unreachable!();
}};
}

/// Assert a condition and panic with the given error if it is false.
///
/// The first argument in the list must be a reference to an [Env].
///
/// The second argument is an expression that if resolves to `false` will cause
/// a panic with the error in the third argument.
///
/// The third argument is an error value. The error value will be given to any
/// calling contract.
///
/// Equivalent to `assert!`, but with an error value instead of a string. The
/// error value will be given to any calling contract.
///
/// See [`contracterror`] for how to define an error type.
#[macro_export]
macro_rules! assert_error {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose the name assert_error because it parallels panic_error (which parallels panic_any). I don't love the name assert_error, because it reads more like we're asserting that an error should occur, rather than creating an assertion that will cause an error if false. I've gone with consistency, but open to suggestions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it a little misleading. You are not asserting that there is an error, rather the opposite. For near's sdk, they went with require, which I would advocate for.

Also I can't wait until macro's can be bound to types! env.require!(...) reads better to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I can't wait until macro's can be bound to types! env.require!(...) reads better to me.

Is this in development? Do you have a link to the tracking PR / RFC? I can't find it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@leighmcculloch leighmcculloch Nov 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@graydon suggested assert_with_error or assert_or_error.

On it's own I think I prefer assert_or_error over require because it retains the assert vocab. i.e.:

  • assert_or_error
  • panic_error

If we wanted panic_error to also follow, then the _with_error variant would probably fit better, i.e.:

  • assert_with_error
  • panic_with_error.

Thoughts? cc @willemneal @graydon @paulbellamy

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*_with_error makes sense to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up: #752

($env:expr, $cond:expr, $error:expr) => {{
if !($cond) {
$crate::panic_error!($env, $error);
}
}};
}

Expand Down
1 change: 1 addition & 0 deletions soroban-sdk/src/tests.rs
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
#![cfg(test)]

mod contract_add_i32;
mod contract_assert_error;
mod contract_call_stack;
mod contract_invoke;
mod contract_invoker_account;
Expand Down
43 changes: 43 additions & 0 deletions soroban-sdk/src/tests/contract_assert_error.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
use crate as soroban_sdk;
use soroban_sdk::{contractimpl, xdr::ScStatusType, Env, Status};
use soroban_sdk_macros::contracterror;

pub struct Contract;

#[contracterror]
#[derive(Copy, Clone, Debug, Eq, PartialEq)]
pub enum Error {
Zero = 1,
}

#[contractimpl]
impl Contract {
pub fn assert(env: Env, value: u32) -> u32 {
assert_error!(&env, value > 0, Error::Zero);
value
}
}

#[test]
#[should_panic(expected = "Status(ContractError(1)")]
fn test_invoke_expect_status() {
let e = Env::default();
let contract_id = e.register_contract(None, Contract);

ContractClient::new(&e, &contract_id).assert(&0);
}

#[test]
fn test_try_invoke() {
let e = Env::default();
let contract_id = e.register_contract(None, Contract);

let res = ContractClient::new(&e, &contract_id).try_assert(&0);
assert_eq!(
res,
Err(Ok(Status::from_type_and_code(
ScStatusType::ContractError,
1,
)))
);
}