Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Parsing crfiteriaFind()- syntax errors?

 
Patrick Cobbett
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How should we respond to syntax errors when parsing the string supplied to criteriaFind()?
Should be respond by returning no records or declaring an exception? If we return no records then how will the client distinguish between no results and the occurance of a syntax error?
That method already declares a DatabaseException but for other reasons. Perhaps also declare a SyntaxErrorException aswell?.. or make it extend DatabaseException. At the moment my implementation returns no records but is this really what we want?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Patrick,
In my assignement, I have a different version of findByCriteria() (which doesn't declare any exception BTW). So in particular I don't know how your DatabaseException purpose is described (I just suppose it's a checked one).
If DatabaseException (as its name implies) has a quite generic description, probably the best is to throw it, using the new exception chaining facility.
Pros :
  • It's a checked exception


  • Cons :
  • The caller will need to call the getCause() method to differentiate your syntax error case from other DatabaseException possible causes.


  • The other solution seems to be throwing a SyntaxErrorException directly, for all that :
  • you extend it from RuntimeException (because you cannot change the provided interface)
  • you catch it within caller code
  • you document it by a @throws javadoc clause


  • Hope that helps,
    Regards,
    Phil.
     
    Patrick Cobbett
    Ranch Hand
    Posts: 44
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Phil, thanks. I'm actually using jdk v1.3. I could as you say use the new chaining functionality offered by v1.4, but then i wouldn't be able to justify code i'd already written using v1.3 which can be handled in v1.4, such as using the Pattern API, also offered. Admittedly i'm being lazy but would rather get this project done and dusted asap.
    DatabaseException is generic, so is it feasible to make SyntaxErrorException extend DatabaseException and test for it using 'instanceof'?
    The requirements doesn't specify what should be done in the event of a syntax error. It only says in the requirements that:
    <i>'The method returns an array of DataInfo objects describing all the records found in the database which match these criteria. In the event of an invalid field name being provided as part of the criteria the behavior of this method is the same as if no records matched correctly specified criteria.'</i>
    I would have thought that an invalid field name should also throw an exception of some sort. Perhaps by returning no records i'm simply declaring that no results are returned, rather than that the criteria specified does return any records. In the latter, returning no records due to a syntax error would be inconsistant with the contract. I hope you're following me.
    The requirements doesn't specify what to do, so perhaps any solution is acceptable provided it is well documented. It's just that if the user interface allowed the user to specify command line queries, then surely it WOULD expect to know the source of error with an appropriate message? But wouldn't the user also want to know that no results were returned due to an invalid field name??? There's just a sense of inconsistency here.
    By returning no records, the contract is s
     
    Philippe Maquet
    Bartender
    Posts: 1872
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Patrick,
    DatabaseException is generic, so is it feasible to make SyntaxErrorException extend DatabaseException and test for it using 'instanceof'?

    Yes ! It's same functionality as exceptions chaining, just another way to achieve it.
    The requirements doesn't specify what should be done in the event of a syntax error. It only says in the requirements that:
    <i>'The method returns an array of DataInfo objects describing all the records found in the database which match these criteria. In the event of an invalid field name being provided as part of the criteria the behavior of this method is the same as if no records matched correctly specified criteria.'</i>

    Oops ! An invalid field name is a syntax exception, even probably 90% of the syntax exceptions possible causes. The specs are bad (IMHO), but ... they are your specs (if - as I have - you have a section with a name like "automatic failure", read it back carefully... ). Reading your specs, I think that you have no choice : if you encounter an invalid field name, simply return an empty array (or whatever you need to return in the case of "no records matched correctly specified criteria" (perhaps null ?)).
    I would have thought that an invalid field name should also throw an exception of some sort. Perhaps by returning no records i'm simply declaring that no results are returned, rather than that the criteria specified does return any records.

    I agree, it's better, but it goes against the specs IMO.
    The requirements doesn't specify what to do, so perhaps any solution is acceptable provided it is well documented.

    I don't agree (see above).
    It's just that if the user interface allowed the user to specify command line queries, then surely it WOULD expect to know the source of error with an appropriate message? But wouldn't the user also want to know that no results were returned due to an invalid field name??? There's just a sense of inconsistency here.

    I fully agree with the first part, but there is no inconstency : just bad design.
    Facing such requirements, I would :
  • implement them just as described in the specs
  • point out the issue in my "design choices" file (named "choices.txt" in my assignment)


  • Cheers,
    Phil.
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Patrick

    Patrick The requirements doesn't specify what should be done in the event of a syntax error.

    I chose to try and cater for most syntax errors as close to the spirit of the instructions as possible. So if a user specified a column name but no value, then I treated it as they wanted to find records with no data in that column. If they provided a value with no column name, then I returned no data. And so on.
    Instructions: ... In the event of an invalid field name being provided as part of the criteria the behavior of this method is the same as if no records matched correctly specified criteria.
    Patrick: I would have thought that an invalid field name should also throw an exception of some sort.

    I agree in principal. However we do not have the luxury of going to the specifications writer and explaining what we want changed and why we want it changed. Therefore we have to accept what we have been given. So we cannot throw an exception for an invalid field name.
    This can even happen in a real life scenario, where the spec you have to implement is tied to a spec for different software that someone in another company is implementing (e.g. you writer server, and they write client). So you cannot get your spec changed as this will affect the other person.
    Regards, Andrew
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic