A, a topic worthy of discussion!

To start of the list of Pro's and Con's (please expand if you know more:

*1) Only the CDK-exception is ever thrown.*
*Pro: **Absolutely none* that I can think of..
*Con: *very hard/unstable to programmatically handle disaster-recovery. If a
method throws a CDK-exception, you have to parse the message string to find
out what happened (was it a Null I entered, or did the IO-connection die?).
As soon as you need to parse user-targeted strings to handle program flow,
you KNOW you're doing something wrong.
In the very least, we should consistently set the nested Cause-exception.

*2) Custom CDK-only exceptions (extends CDK-exception)*
*Pro:* Programmatic error-handling becomes possible, as you can now
differentiate between the different causes in your try-catch blocks
*Con:* You need to (partially) re-invent the wheel. (because strictly
speaking, this style mandates that if you enter a bogus file-path into
example.readFromMol, you must get a CDKFileNotFound exception...)

*3) Java core exceptions only*
*Pro:* no need to come up with our own exceptions
*Con: *loss of detail when chemistry-specific problems pop up. (e.g. Why
throw an IllegalArgumentException when a "NoSuchIsotopeException("element
#204 doesn't exist") would provide more detail?)


As Nina already pointed out: a mix is possible. We could make a hierarchy of
"extends CDK-exception".
E.G.
CDKException > InputException > ParseException > MolFileParseException
                                                > ParseException >
InvalidSmilesException
                      > InputException > ChemistryViolation >
MaximumBondOrderExceeded
e.t.c.

My "perfect solution" would be to re-use Java-core exceptions where they
make sense, and add "CustomException Extends CDKException" where needed. And
when there's a perfectly valid Java-core exception, why not use it?

E.g. If I'm loading a lengthy SDF-file from a network-drive, and the network
connection drops halfway, I see no reason why we shouldn't pass the
FileNotFoundException straigth up; no need to wrap it in a CDKException,
because the CDK didn't cause it.
Also, if you are trying to pass, say, a IReactionContainer into the
IMoleculeRenderer, a java-core "IllegalArgumentException" or
"ClassCastException" is perfectly valid.

One of java's core strengths in general  is that the class-hierarchies allow
you a lot of rigid control over program flow and what can and cannot be
done. It would be a waste to throw that away by using only one CDK-exception
or only Java-Core exceptions.

Regards,
Jules

On 6 July 2011 12:06, Egon Willighagen <egon.willigha...@gmail.com> wrote:

> Hi developers *and* users,
>
> shall we try to come up with a good Exception design for master?
>
> Currently, the CDK uses a mix of various CDK specific exceptions,
> though we officially promote the single use of CDKException. Others
> have requested to use more general exceptions, like
> IllegalArgumentException.
>
> Today, another user problem came up, a NPE upon missing 2D coordinates
> in the renderer, where in fact a IllegalArgumentException may be
> appropriate, with a good error message.
>
> I like to discuss this issue, and in particular these three designs:
>
> 1. Only CDKException with proper messages (current formal design of
> the CDK, which several classes violate)
> 2. Use CDK-specific, tuned exceptions, such as NoSuchAtomTypeException
> (existing already) and Missing2DCoordinatesException
> 3. Use Java Exceptions only, like IllegalArgumentException with proper
> messages
>
> There are pros and cons for all of them. Let's try to get them clear first.
>
> Egon
>
>
> --
> Dr E.L. Willighagen
> Postdoctoral Researcher
> Institutet för miljömedicin
> Karolinska Institutet (http://ki.se/imm)
> Homepage: http://egonw.github.com/
> LinkedIn: http://se.linkedin.com/in/egonw
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: http://www.citeulike.org/user/egonw/tag/papers
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Cdk-devel mailing list
> cdk-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Cdk-user mailing list
Cdk-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-user

Reply via email to