Cairo : Plugin diagnostic: The value does not fit within the range of type core::felt252

Question

I've been working on a contract in cairo starknet and i got this error : Plugin diagnostic: The value does not fit within the range of type core::felt252. --> hello_starknet.cairo:54:46 assert(!isFriend(sender, recipient), 'this person is already your friend');

Any idea how to solve this?

I tried something i found on internet but not results :

assert(!isFriend(sender, recipient), TryInto::try_into('this person is already your friend').unwrap());

Answer 1

There is currently no way to handle string on cairo so the default type of any string inputed is felt252 and according to cairo book::

In Cairo, if you don't specify the type of a variable or argument, its type defaults to a field element, represented by the keyword felt252. In the context of Cairo, when we say “a field element” we mean an integer in the range 0≤x<P , where P is a very large prime number currently equal to 2251+17⋅2192+1 . When adding, subtracting, or multiplying, if the result falls outside the specified range of the prime number, an overflow (or underflow) occurs, and an appropriate multiple of P is added or subtracted to bring the result back within the range (i.e., the result is computed modulo P).

The most important difference between integers and field elements is division: Division of field elements (and therefore division in Cairo) is unlike regular CPUs division, where integer division xy is defined as ⌊xy⌋ where the integer part of the quotient is returned (so you get 73=2 ) and it may or may not satisfy the equation xy⋅y==x , depending on the divisibility of x by y.

In Cairo, the result of xy is defined to always satisfy the equation xy⋅y==x . If y divides x as integers, you will get the expected result in Cairo (for example 62 will indeed result in 3). But when y does not divide x, you may get a surprising result: for example, since 2⋅P+12=P+1≡1modP , the value of 12 in Cairo is P+12 (and not 0 or 0.5), as it satisfies the above equation.

Obviously if you reduce the length of your string the error disappears. This is because the longer your string the higher or more likely it is for either an overflow to occur.

SOLUTION:: Use shorter string messages(this is the only solution that works for me so far) you can also make use of identifiers for different error messages and include them in your documentation.