2 comments

• 

  James Langley

  3 years ago

  Hmm. It seems as though there's a danger here of leaking information outside the called method. If I call the parse file method, how do I as the caller know what to do if there's a problem parsing the document? If I'm expected to know that, then you can just make that feature part of the API - "I'll call you back when there's a problem parsing the file". Perhaps I'm missing something but I'm not sure that this doesn't solve a problem that soluble in other ways.
  reply
• 

  Phil Dawes

  3 years ago

  Hi James,
  
  The caller knows what to do because it has requirements it wants to fulfill. If you want a parser that silently ignores the errors you write an exception handler that invokes the 'skip-line' restart. If you want to log you do that etc..
  
  This problem is certainly solvable in other ways - you could implement an error callback, or maybe an abstract base class or strategy pattern or something. AFAICS the benefit of the condition system is that it's quick and easy to do the right thing upfront - you defer the error conditions to the caller, who is more likely to know what it wants to do and can change later.
  
  E.g. If I'm writing a parse function in python/java I don't think 'this should be an abstract base class because I might want to reuse it in other circumstances later' - I just write and test the function (simplest thing).
  Then when the program wants to ignore unparseable lines I might add a flag-argument to the function. Finally I might refactor it into a class structure later when I need to use it in other systems.
  With conditions I just add the resume points to the function - the refactoring is small and idiomatic.
  
  (btw, it's early days for me and common lisp, so I don't have any practical experience of how well this works)
  reply