On 6 July 2011 15:26, Syed Asad Rahman <s9a...@gmail.com> wrote:
> I too agree that exceptions should be problem related rather than module
> related.
>
This is fine, I don't have strong arguments on either choice, just having
something agreed, so that
1) it is more or less clear for a new developer what exception to use
2) ensure easy tracking where the exception comes from (hopefully modules
are problem oriented themselves)
Guess the final decision will be a mixed approach.
Nina
>
> Asad
> On 6 Jul 2011, at 13:22, Rajarshi Guha wrote:
>
> > On Wed, Jul 6, 2011 at 7:50 AM, 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
> >>
> >> 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'd argue that even that is too many (initially). The nature of a
> > module could change over time; rather, if exceptions are modeled on
> > the nature of the problem causing the exception (no atom type etc), we
> > can maintain some control over the number of exception classes
> >
> > --
> > Rajarshi Guha
> > NIH Chemical Genomics Center
> >
> >
> ------------------------------------------------------------------------------
> > 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
