[stringtemplate-interest] which ST errors are serious

[Brain, Jim]

It's true you'd need to unconditionally pass things to the listener, but it seems a worthwhile tradeoff.

My concern mainly comes from maintenance programming.  Even conditionally not sending events means that a maintenance programmer could be doing:

EventHandler() {
onMalformedTemplate(...) {
...
}
onMissingTemplate(...) {
 // Maintenance programmer:  ST4 is BORKED!  It says to add this handler to handle missing Templates, so I did this, but the event NEVER FIRES.  Filing a bug report with Terrence now!
}
}

When the original programmer did (in a far away piece of code):

// just ignore missing templates in prod.
//STStatic.setEventList(MALFORMED_TEMPLATE | MISSING_TEMPLATE);
STStatic.setEventList(MALFORMED_TEMPLATE);

As always, there will no doubt be a chorus of "RTFM", but I think it is reasonable to expect a library to pass all of the events to the listener, all the time, and I can decide which ones I care about and how I choose the proceed.

I understand some folks wish to silently ignore missing templates, while others need alerts, and others need Exceptions.  Still, I think the behavior of the library should be absolutely deterministic (ST4 will fire an event on all warnings or errors) and then let the library user decide how to interpret based on their situation.  In other words, ST4 is about being a great template engine, not about being a configuration system for error handling.

Of course, folks can still argue about on<Event>() versus onEvent(EVNT_TYPE, ...), but I'll steer clear of that one.

Jim


From: Terence Parr [mailto:parrt at cs.usfca.edu]
Sent: Tuesday, December 01, 2009 12:22 PM
To: Brain, Jim
Cc: stringtemplate-interest at antlr.org List
Subject: Re: [stringtemplate-interest] which ST errors are serious


On Dec 1, 2009, at 7:55 AM, Brain, Jim wrote:


If you have a listener concept in v4 and will pass the errors to the listener, it seems to me that someone who needs Exceptions can just throw the exception in the listener.

That's true. they can decide what's fatal. i'll have to pass more info to the listener this way though and can't manage a bitset of what to pay attention to.


Is it common in systems to have a "conditional Exception system" like this, where the same conditions may or may not throw Exceptions depending on some configuration setting?  If so, I'm unfamiliar with it.  From a language perspective, I much prefer Exceptions either be "always" or "never", not "optional"

Well, in many ways it's a way to specify language semantics depending on your situation. Some rely on <a.b> being valid when b doesn't exist.  Some people consider it a programming error.  Both use cases are valid.

As u say, maybe pass everything to listener and it can decide...

Ter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091201/d86e026a/attachment-0001.html