-
Notifications
You must be signed in to change notification settings - Fork 773
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
refactor(experimental): errors: addresses
package
#2187
refactor(experimental): errors: addresses
package
#2187
Conversation
d8ebcf5
to
399694b
Compare
1b48e25
to
91b4a68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather have these all as separate error codes. You can always catch the SolanaError
without caring what type it is.
try {
const pda = await createProgramDerivedAddress(/* ... */);
} catch(e) {
if (isSolanaError(e)) {
// bad thing
} else {
throw e;
}
}
I see that this sub-error thing happens in later PRs too. Listen, one thing we could do is to to make use of throw new SolanaError(SOLANA_ERROR__PDA_SUCKS, {
cause: new SolanaError(
SOLANA_ERROR__PDA_SPECIFICALLY_SUCKS_BECAUSE_OF_THIS,
{ /* context for cause */ },
),
/* other context */
}); Then people can be like: try {
const pda = await createProgramDerivedAddress(/* ... */);
} catch (e) {
if (isSolanaError(e, SOLANA_ERROR__PDA_SUCKS)) {
const why = e.cause;
// Do something with `cause`, or not.
} else {
throw e;
}
} I don't love it though. If we can get away without doing that, we probably should. If there are good use cases for sub-errors, then we should lean on Notes:
|
399694b
to
f32df50
Compare
91b4a68
to
2bf93b9
Compare
Alright I think I got the message, guys. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
throw new SolanaError(SOLANA_ERROR__INCORRECT_BASE58_ADDRESS_LENGTH, { | ||
actualLength: putativeAddress.length, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I wrote this error it was intended to be a fast-path check on the number of bytes, without actually counting the number of bytes. Like, looking at the string length of the base 58 string is enough to tell you that it's definitely not 32 bytes, without knowing exactly how many bytes you're dealing with.
This, all to say that I think this error and the one below it are meant to be the same one, and that it's not actually interesting to know how long the base 58 string is.
Maybe make them the same error, and make actualLength: number | 'UNKNOWN'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a bad check, and the code is (somewhat) informative, but I can see how the two errors could be merged. I'm not really a huge fan of actualLength: 'UNKNOWN'
, and I certainly don't think we should decode the string just to return the real actual byte length, which could invoke another unrelated error.
I think where I'm hesitant is "what do I do if my string is < 32
or > 44
"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SOLANA_ERROR__WHERE_DID_YOU_EVEN_GET_THIS
} | ||
// Slow-path; actually attempt to decode the input string. | ||
const base58Encoder = getMemoizedBase58Encoder(); | ||
const bytes = base58Encoder.encode(putativeAddress); | ||
const numBytes = bytes.byteLength; | ||
if (numBytes !== 32) { | ||
throw new Error(`Expected input string to decode to a byte array of length 32. Actual length: ${numBytes}`); | ||
throw new SolanaError(SOLANA_ERROR__INCORRECT_BASE58_ADDRESS_BYTE_LENGTH, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that it's important, at this point, that the address used to be base58 encoded. The error is that the address itself has the wrong byte length.
throw new SolanaError(SOLANA_ERROR__INCORRECT_BASE58_ADDRESS_BYTE_LENGTH, { | |
throw new SolanaError(SOLANA_ERROR__INCORRECT_ADDRESS_BYTE_LENGTH, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It really only makes sense to include the _BASE58
to match the pattern of the error code above it, if it remains in the set.
packages/errors/src/context.ts
Outdated
index: number; | ||
maxSeedLength: number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to think of what I would do with this error. It basically tells me that ‘some seed in this call’ was too long, but not how long it was, nor what the seed was. Also, it makes a value the maximum seed length that probably won't change in our lifetimes, at least not without a code change being necessary in web3.js.
On the other hand, inlining the seed into the error is maybe a bad idea (privacy?).
I'm struggling to think of what this error context could contain that would actually help me fix the bug. Maybe the actual length of the violating seed is a start?
In any case, it's an important question to ask for each error: ‘does this context help the developer find the bug.’
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it makes a value the maximum seed length that probably won't change in our lifetimes, at least not without a code change being necessary in web3.js.
Yeah, but I really didn't want to have to introduce two areas where we'd have to change that value, if we ever needed to update the code.
On the other hand, inlining the seed into the error is maybe a bad idea (privacy?).
Probably safe to avoid this, yeah.
I'm struggling to think of what this error context could contain that would actually help me fix the bug. Maybe the actual length of the violating seed is a start?
Index and actual length should do, no? I doubt we need more than that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, the MAX_SEEDS
error gets thrown by createProgramAddress
(also the case in the Rust library as well). This can be confusing to the downstream user, since if they provide 16 seeds (MAX_SEEDS
), they'll actually be feeding createProgramAddress
with 17 seeds, because the bump is included, and they'll get this error.
With the changes I have locally right now, you'd basically get a message "provided: 17" when you can visibly see you only provided 16. Is a descriptive message good enough to elaborate this fact? Or do we want to work out the "max seeds" concept to actually be 15?
f32df50
to
a3b445e
Compare
2bf93b9
to
b10a9e8
Compare
a3b445e
to
1bc1537
Compare
b10a9e8
to
bb22886
Compare
Merge activity
|
1bc1537
to
8608dc7
Compare
bb22886
to
16ce665
Compare
🎉 This PR is included in version 1.90.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up. |
Adds custom
SolanaError
throws to the@solana/addresses
package.