Open drgorillamd opened 10 months ago
Thanks for pointing this out! Having clearer error messages for incorrect constructor syntax, like #[aztec(private)], and enforcing constructor presence during compilation would greatly improve the Solidity development experience. These enhancements could streamline debugging and benefit developers, especially when switching contexts between languages. Improving error handling in Solidity aligns with creating a more user-friendly environment. Your insights are valuable for enhancing the language’s usability and reliability!
ike #[aztec(private)],
Should have added (but I guess it's a nice way to demonstrate it), here, the issue is a missing fn
e: and the "error handling" is in Noir, not Solidity... GitHub spam?
Okay so there are really two fixes:
Expected an end of input but found contract
Thanks for flagging this @drgorillamd
@rahul-kothari For 1., the expected out of input at least point in the right direction of a syntax error, the really big pain is if it throws compute_note_hash_and_nullifier function not found
(too aggressively hunting for such?), which mislead to an implementation issue (ergo pain, despair, tears, etc)
Jyst added a compile time error if constructor is missing. Noir team will be looking into better function errors
Great! ty! Commented the commit @rahul-kothari , maybe we can catch both issues there (I know, a tad hacky tho)
TL;DR: wrong constructor syntax should be caught and have a proper error message, same as a missing constructor.
It would be nice to have a specific error message when using this (wrong) syntax:
as this fails to compile either with a generic parsing error (
Expected an end of input but found contract
, which is easy to understand) or, if storage is used and there is some logic inside the constructor, acompute_note_hash_and_nullifier function not found
(yes, this is a bit painful to debug the first time).A missing constructor isn't currently caught before attempting to deploy (while it is a mandatory fn), maybe it would be nice to enforce this when compiling.
Rationale is, due to context switching with Solidity or JS (which I guess is to expect), these are difficult errors to catch, especially with the misleading compute_note_hash_and_nullifier error (Rustaceans should be fine tho).