I am very against the idea of runtime failures. That's the whole point of a type safe fluent API.

I would rather put the effort on the framework side than on the developer side. A string query language or a dynamic language is better if you are not bothered with helping the developer to write the query. On 20 nov. 2009, at 12:31, Navin Surtani <nsurtani(a)redhat.com&gt; wrote: > Heya, > > I was just thinking last night about a couple of things about the > DSL. > > Mainly, instead of having lots of return types, for example you > created a BooleanContext and a Negatable version if the Occur > clause was MUST. I was wondering, instead of having separate > contexts, is it easier to have one - and then if a user calls a > buildQuery() without sufficient information to actually build one > we throw an exception? > > I think this is cleaner in some ways because we don't have to > create so many different types of class, and we're always returning > the same instance. However, the drawback is that by this method we > "allow the user to make a mistake" and will be needing to throw > exceptions. So here's where the discussion starts - what are pros/ > cons of each system and which wind up being a better one to build? > Personally, I think having a single class context is better because > 1 - it's simpler to build and 2 - as long as classes are documented > properly and exceptions thrown are clear as to what the issue is > then we're okay. > > Ideas? Thoughts? > > Navin Surtani > > Intern Infinispan > Intern JBoss Cache Searchable >