hmm... if it's in the documentation, log AND exception message, that doesn't seem so bad...
I'll pause here for a day to see if anyone else wants to defend my side. WILL On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > Thanks, Nathan, that's a good way to put it. All people need to do is > set > > a config option to make existing apps work. > > > > The challenge is getting 100% of upgrading users to find this > info. We'd > > need to highlight this in a README, in the docs, and answer tech support > > questions on this. And there may still users who miss it. Yes, it > might be > > their own fault, but that's still a dent in our rep for those users. > > Put the info right into the exception message, as i suggested. Then > the users who need can't miss it! Something like the following should > do the trick: > > ParseErrorException: Your macro call contained the wrong number of > arguments. To allow this behavior, set > 'velocimacro.break.on.wrong.argument.count = false' in your > velocity.properties. > > i can have some sympathy for those who don't read the manual, change > logs, readmes, or release notes. i have no sympathy for those who > don't read exception messages and then whine about the exception. > part of that is because i've never heard of such a person. :) > > > (we can balance this against tech support for new users who should see > macro > > errors but don't. pretty minimal to date). > > > > For other similar issues (e.g. allowing set's to set null's) we've made > the > > config default to old behavior. Minor though this seems, it's enough of > an > > exception I'd like to hear from other committers before giving up our > goal > > of 100% "drop-in" replacement. > > Just for the record, i have never understood that goal to include > buggy behavior. :) so i don't think we'd be dropping the goal at all. > > > WILL > > > > On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > > > If i may be forgiven one last push... :) > > > > > > Let's keep the story straight--you wouldn't have to edit the old apps > > > to make them work with 1.5. You just have to set the config property, > > > not really a great burden. We could even make the message with the > > > thrown exception point out the new config property, so that those who > > > don't read change logs or release notes will have no problem figuring > > > out what's going on. > > > > > > On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > > > I feel strongly about this. > > > > > > > > I've personally got hundreds of templates in production and support > > > users > > > > with hundreds more. Say 5% of those templates have this > error. (It's > > > not > > > > hard to make -- note that the Velocity test suite for Anakia > contains > > > this > > > > error). All of a sudden I have tens of templates, scattered all > over > > > the > > > > place that suddenly cause errors. All of those apps work right now- > why > > > do > > > > I want them to fail? Anything that requires me to edit old apps to > make > > > > Velocity 1.5 work is not backwards compatible. (and will retard > > > adoption of > > > > 1.5). > > > > > > > > It would have been nicer if this had always generated an error. For > new > > > > apps this is better. But for old apps it is actively harmful to > change > > > > this. So let's make this a config option and turn it on by default > for > > > 2.0 > > > > . > > > > > > > > WILL > > > > > > > > On 3/21/06, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On 3/21/06, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > > > > > > I'm starting to agree with you, Llwellyn. Though I don't think > we > > > > > should > > > > > > change the behavior of the templates for existing users. > > > > > > > > > > even if the behavior is buggy/broken? it's not like the extra or > > > > > missing arguments were doing anything functionally. throwing an > > > > > exception, however, will add functionality (as Malcom > demonstrated. > > > > > we already warned that their macro call was broken in the logs, i > > > > > think it is fair to escalate that to an exception, especially if > we > > > > > provide a config option to log instead of throw an exception. > > > > > > > > > > of course, if you feel strongly about this, i won't -1 a log-only > > > > > default, and i'll let them that do the work implement it the way > they > > > > > want :). it's just my opinion; i won't be dogmatic on it. :) > > > > > > > > > > > > > > > > > WILL > > > > > > > > > > > > On 3/21/06, Llewellyn Falco <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > Personally, i feel that templates whose macro calls don't > match > > > up > > > > > to > > > > > > > > the macro definitions are *already* broken. > > > > > > > > > > > > > > this is my general thought on the whole thing too. > > > > > > > > > > > > > > and as we deal in financial transactions, I take a general > view of > > > > > > > it is better not to show something than to show something > wrong. > > > > > > > > > > > > > > however, I can understand that in an entertainment situation > you > > > might > > > > > > > have > > > > > > > the exact opposite view. > > > > > > > again though, I think this goes back to a 2 modes of running. > > > > > > > > > > > > > > development - always halt on errors - someone's there to fix > them. > > > > > > > deployment - do the best you can - log what goes wrong > > > > > > > > > > > > > > and see a setting much more in this idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > btw: this is also why I always develop with the > UberspectTestImpl > > > and > > > > > > > rather > > > > > > > think that it should be default Uberspect, while currently it > is > > > only > > > > > in > > > > > > > the > > > > > > > test classes. > > > > > > > > > > > > > > Llewellyn. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Forio Business Simulations > > > > > > > > > > > > Will Glass-Husain > > > > > > [EMAIL PROTECTED] > > > > > > www.forio.com > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Forio Business Simulations > > > > > > > > Will Glass-Husain > > > > [EMAIL PROTECTED] > > > > www.forio.com > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Forio Business Simulations > > > > Will Glass-Husain > > [EMAIL PROTECTED] > > www.forio.com > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
