Tilakkumar / cleartk

Automatically exported from code.google.com/p/cleartk
0 stars 0 forks source link

introduce CleartkException #89

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I would like to propose that we introduce a class called
org.cleartk.CleartkException that we use for interfaces.  A lot of our
interface methods do not throw an exception which can be really annoying. 
I suggest, for example, that the signature for Classifier.classify should
look like this:

public OUTCOME_TYPE classify(List<Feature> features) throws CleartkException;

Opinions?

Original issue reported on code.google.com by pvogren@gmail.com on 22 Apr 2009 at 5:26

GoogleCodeExporter commented 8 years ago
Agree -- not necessarily only for interfaces. We should still take care to 
allow other reasonable exceptions to be 
thrown where applicable (for example, IOException is a reasonable thing to 
throw in some cases). But there are a 
lot of places where things can go wrong in various unexpected ways, and it 
would be very good to be able to 
throw an exception that wraps the one causing the problem and is NOT 
RuntimeException.

Original comment by phwetz...@gmail.com on 22 Apr 2009 at 5:32

GoogleCodeExporter commented 8 years ago
I have introduced the CleartkException in a number of places - esp. in the 
classifier
package.  I tried to make a reasonable guess as to where it would be most
appropriate.  For example, the classify, consume, and write interface methods 
along
with their implbases throw them.  But methods like expectsOutcomes do not throw 
one
because this is usually simply returning a flag that has already been set.  In 
some
cases I left the exception that was already there.  For example,
Classifier_ImplBase's constructor still throws an IOException - because given 
that
the input parameter is a JarFile - this seems like the most appropriate 
exception.  

I'm not perfectly clear on what best practices are.  Hopefully, this is a 
reasonable
first stab.  

Original comment by pvogren@gmail.com on 23 Apr 2009 at 9:03

GoogleCodeExporter commented 8 years ago
I think it is safe to close this issue.  let's remember to use this exception 
when
appropriate.

Original comment by pvogren@gmail.com on 5 May 2009 at 2:54