Egon wrote:
> Interesting you bring this up. Exceptions should not be used for code
flow.
I agree, to a point; Exceptions should handle exceptional cases; returning
to my often-used file-not-found example: it is very okay for a program to
intercept the file not being available. Perhaps it can intelligently fall
back to a second mirror, or present a custom popup to the user requesting a
new location, etc.
This behaviour falls within my definition of "program-flow", as does, in my
opinion, the general case of 'failing gracefully'. Maybe our definitions of
"program flow" differ?
Nina Wrote:
> Hundreds of descendant of the top CDKException class doesn't sound good
indeed
> One idea is to have first level of sub-classes restricted for one per
package/module. The subsequent levels will depend
> on what is needed inside the module.
I very much like this idea;
I agree with Rajarshi that the exception-tree should be kept lean. (In
retrospect, maybe my example of one ParseException per fileformat was
already a bit much, one "ParseException" with the message specifying the
problem would probably do as well. Especially with the new errorhandler that
was recently added.)
~Jules
On 6 July 2011 13:50, Nina Jeliazkova <jeliazkova.n...@gmail.com> wrote:
>
>
> On 6 July 2011 14:42, Rajarshi Guha <rajarshi.g...@gmail.com> wrote:
>
>> I like Jules suggestions - use Java exceptions where possible/
>> reasonable, but have a hierarchy of CDKExceptions; my worry is that it
>> will be easy to have a proliferation of CDKException subclasses, such
>> that rather than throw an appropriate class, code will just throw the
>> most generic exception. if we do go for a hierarchy, I would suggest
>> to keep it as lean as possible
>>
>
> Hundreds of descendant of the top CDKException class doesn't sound good
> indeed.
>
> One idea is to have first level of sub-classes restricted for one per
> package/module. The subsequent levels will depend on what is needed inside
> the module.
>
> Regards,
> Nina
>
>>
>> On Jul 6, 2011, at 6:06 AM, Egon Willighagen 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
>>
>> ----------------------------------------------------
>> Rajarshi Guha | NIH Chemical Genomics Center
>> http://www.rguha.net | http://ncgc.nih.gov
>> ----------------------------------------------------
>> Finally I am becoming stupider no more
>> - Paul Erdos' epitaph
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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-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
