Re: [Firebird-devel] Current handling of precision in syntax
On 27-7-2019 14:35, Mark Rotteveel wrote: On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote: On 27/07/2019 07:57, Mark Rotteveel wrote: When working on my pull request for FLOAT, I noticed that the way that the precision fragments (ie precision_opt and precision_opt_nz) works in the grammar yields non-intuitive error messages. For example, a negative precision just yields an unclear """ Token unknown - line 10, column 20 - """ Using a zero value with precision_opt_nz yields the slightly better """ Positive value expected At line 10, column 20 """ Better would be to have and error message with the right range for the type (which is usually done for positive values that are not valid). Is there a reason that isn't currently done? I disagree. If a rule can catch the problem, let it be. Token unknown happens for all rules used incorrectly. From a perspective of user experience, I disagree. I think clear error messages should be preferred. As another datapoint, Firebird is currently inconsistent in this regard. For NUMERIC(p), NUMERIC(p,s), DECIMAL(p) and DECIMAL(p,s) it does give proper feedback about the valid range, and it doesn't restrict this to non-negative integers only in the grammar. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current handling of precision in syntax
On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote: On 27/07/2019 07:57, Mark Rotteveel wrote: When working on my pull request for FLOAT, I noticed that the way that the precision fragments (ie precision_opt and precision_opt_nz) works in the grammar yields non-intuitive error messages. For example, a negative precision just yields an unclear """ Token unknown - line 10, column 20 - """ Using a zero value with precision_opt_nz yields the slightly better """ Positive value expected At line 10, column 20 """ Better would be to have and error message with the right range for the type (which is usually done for positive values that are not valid). Is there a reason that isn't currently done? I disagree. If a rule can catch the problem, let it be. Token unknown happens for all rules used incorrectly. From a perspective of user experience, I disagree. I think clear error messages should be preferred. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Current handling of precision in syntax
On 27/07/2019 07:57, Mark Rotteveel wrote: > When working on my pull request for FLOAT, I noticed that the way that > the precision fragments (ie precision_opt and precision_opt_nz) works in > the grammar yields non-intuitive error messages. > > For example, a negative precision just yields an unclear > """ > Token unknown - line 10, column 20 > - > """ > > Using a zero value with precision_opt_nz yields the slightly better > """ > Positive value expected > At line 10, column 20 > """ > > Better would be to have and error message with the right range for the > type (which is usually done for positive values that are not valid). > > Is there a reason that isn't currently done? > I disagree. If a rule can catch the problem, let it be. Token unknown happens for all rules used incorrectly. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Current handling of precision in syntax
When working on my pull request for FLOAT, I noticed that the way that the precision fragments (ie precision_opt and precision_opt_nz) works in the grammar yields non-intuitive error messages. For example, a negative precision just yields an unclear """ Token unknown - line 10, column 20 - """ Using a zero value with precision_opt_nz yields the slightly better """ Positive value expected At line 10, column 20 """ Better would be to have and error message with the right range for the type (which is usually done for positive values that are not valid). Is there a reason that isn't currently done? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
