Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Wed, Jul 13, 2011 at 10:33 PM, Thomas Strunz wrote:
> But does it enforce good/non-harmful error handling?
>
> I would say a very large amount will be infamous:
>
> try{
> ...
> } catch(Exception ex){
> }
>
> or
>
> try{
> ...
> } catch(Exception ex){
> ex.printStacksTrace()
> }
Ah, not to disarm you from your argument... but this can be catched
with PMD. (Of course, people do need to use it :)
> I mean checked exceptions assume developers are bad/lazy (eg. can't document
> and don't read documentation) but they expect them to be able to do proper
> exception handling?
Still, the community moves in a better scientific code base quality...
think, the "Open Research Computation"
(http://www.openresearchcomputation.com/).
> Anyway, maybe I'm just too inexperienced to see the reason. The most
> important thing for CDK is to throw exceptions more granular.
Yes, I think we all support that aspect.
> If you catch a
> CDKException right now I'm still pretty clueless what it actually means (IO;
> AtomType,...).
Yes, and we will move away from that...
BTW, did someone stand up to draft a proposal (can be informal, no big
deal, just for further discussions...)
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
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Cdk-user mailing list
Cdk-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hi Sulev, I would go even further and remove checked exceptions completely. The documentation should state which exceptions are thrown in a method an hence the developer knows and can decide on his own if he wants to deal with it. If he doesn't want to deal with it, he will do as you said which often makes the situation worse. It's like treating someone as a child and the reaction to that is mostly not very friendly. It's no wonder a lot of well known frameworks don't use checked exceptions at all in facts the wrap them in runtime exceptions. So IMHO: 1. only runtimeexceptions (wrap checked excpetions eg IOExcpetions) 2. create more specific exceptions that ca be selectivley dealt with in try..catch I often get CDKException thrown when typing Atoms. And in that case my input is correct but CDK does not know how to deal with it. pretty annoying. ->UnknownAtomTypeException maybe? Best Regards, Thomas > Date: Wed, 6 Jul 2011 16:08:39 +0300 > From: s...@chem.ut.ee > To: vincent.le-guill...@univ-orleans.fr > CC: cdk-user@lists.sourceforge.net > Subject: Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What > will we use in the next CDK series (1.6 or 2.0)? > > Hello, > > On Jul 06, Vincent Le Guilloux wrote: > > I would also roughly go to the Nina's solution, with a strong > > agreement with Rajarshi. Just a few additional word to enrich this > > interesting discussion: > > I also like that suggestion. > > > > Too much exceptions handling / types usually gives verbose code (JAVA > > is verbose enough hu... ;)), endless try/catch at every level of the > > code, and bad performances. > > This reminds me the old debate about checked versus unchecked exceptions. > There is a good summary about this topic: > http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html > > One approach would be to have both checked and unchecked exceptions > in the CDK API. Checked exceptions are used only for cases where the > programmer has an obvios way for recovering the exceptional situation. > The rest are runtime exceptions (could inherit from CdkRuntimeException). > I've observed that checked exceptions in code are rarely handled, they > are usually rethrown, logged, or swallowed. > > Best wishes, > Sulev > > -- > 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 -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Good to know indeed, thanks :)
2011/7/8 Egon Willighagen
> On Thu, Jul 7, 2011 at 9:56 PM, Vincent Le Guilloux
> wrote:
> > Yes indeed; is it that bad ? :)
>
> No, not particularly, but it is good to know there is an option to
> force reading coordinates as 3D :)
>
> MDLV2000Reader reader = new MDLV2000Reader(ins);
>Properties prop = new Properties();
>prop.setProperty("ForceReadAs3DCoordinates","true");
>PropertiesListener listener = new PropertiesListener(prop);
>reader.addChemObjectIOListener(listener);
>reader.customizeJob();
>
> The listener bit is historical... I guess this API will simplify in
> the next series.
>
> 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-user mailing list
Cdk-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Thu, Jul 7, 2011 at 9:56 PM, Vincent Le Guilloux
wrote:
> Yes indeed; is it that bad ? :)
No, not particularly, but it is good to know there is an option to
force reading coordinates as 3D :)
MDLV2000Reader reader = new MDLV2000Reader(ins);
Properties prop = new Properties();
prop.setProperty("ForceReadAs3DCoordinates","true");
PropertiesListener listener = new PropertiesListener(prop);
reader.addChemObjectIOListener(listener);
reader.customizeJob();
The listener bit is historical... I guess this API will simplify in
the next series.
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-user mailing list
Cdk-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Yes indeed; is it that bad ? :) 2011/7/7 Egon Willighagen > On Thu, Jul 7, 2011 at 7:43 PM, Vincent Le Guilloux > wrote: > > Anyways, I think the 2D / 3D coordinates checks could be improved > (removed > > ?). I've experienced a lot of cases where planar molecules are perceived > as > > 2D molecules and thus can't be used with 3D descriptors. > > You must be reading MDL molfiles or SD files then :) > > 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Thu, Jul 7, 2011 at 7:43 PM, Vincent Le Guilloux wrote: > Anyways, I think the 2D / 3D coordinates checks could be improved (removed > ?). I've experienced a lot of cases where planar molecules are perceived as > 2D molecules and thus can't be used with 3D descriptors. You must be reading MDL molfiles or SD files then :) 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
I think there is a misunderstanding :) let's clarify what I said then, because I realize I wasn't very clear: When I say that an Exception is thrown, I mean that the getException() returns an actual exception. And when I say that sometimes, NaN value are returned, I mean that indeed, for descriptors mixing 2D and 3D descriptors, the results are not null but contains both NaN and valid output values. Which is consistent with what you said, so I don't think there is a any bug here :) Anyways, I think the 2D / 3D coordinates checks could be improved (removed ?). I've experienced a lot of cases where planar molecules are perceived as 2D molecules and thus can't be used with 3D descriptors. 2011/7/7 Rajarshi Guha > Hmm, that shouldn't be happening :( > > On Thu, Jul 7, 2011 at 12:37 PM, Vincent Le Guilloux > wrote: > > > > Quoting Egon Willighagen : > > > >>> Let's take a concrete example in the CDK: when computing 3D > >>> descripors, most of the classes in charge of computing such > >>> descriptors will check that the input molecule actually has 3D > >>> coordinates, and throw an exception otherwise. > >> > >> Actually... there we have a different mechanism, and just return NA :) > >> > > > > In my experience, I have found both mecanism: some descriptors return > > NaN values (while the getException() method returns null), and others > > throws exceptions (in particular when they detect missing 3D > > coordinates). > > > > > > -- > > Vincent Le Guilloux > > > > Phd Student - ICOA - UMR CNRS 6005 > > Div. of chemoinformatic and molecular modeling. > > University of Orléans > > Phone: ++33 2 38 49 45 77 > > Fax : ++33 2 38 41 72 81 > > > > > > > > > -- > > 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 > > > > > > -- > 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hmm, that shouldn't be happening :( On Thu, Jul 7, 2011 at 12:37 PM, Vincent Le Guilloux wrote: > > Quoting Egon Willighagen : > >>> Let's take a concrete example in the CDK: when computing 3D >>> descripors, most of the classes in charge of computing such >>> descriptors will check that the input molecule actually has 3D >>> coordinates, and throw an exception otherwise. >> >> Actually... there we have a different mechanism, and just return NA :) >> > > In my experience, I have found both mecanism: some descriptors return > NaN values (while the getException() method returns null), and others > throws exceptions (in particular when they detect missing 3D > coordinates). > > > -- > Vincent Le Guilloux > > Phd Student - ICOA - UMR CNRS 6005 > Div. of chemoinformatic and molecular modeling. > University of Orléans > Phone: ++33 2 38 49 45 77 > Fax : ++33 2 38 41 72 81 > > > > -- > 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 > -- 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Thu, Jul 7, 2011 at 6:37 PM, Vincent Le Guilloux wrote: > In my experience, I have found both mecanism: some descriptors return NaN > values (while the getException() method returns null), and others throws > exceptions (in particular when they detect missing 3D coordinates). Can you please file a bug report? Then I'll try to write a unit test for it, to test that we do not get Exceptions when no 3D are given... though I think we already might have such a test... anyway, please file a report, and I'll look at it asap. E. -- 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Quoting Egon Willighagen : >> Let's take a concrete example in the CDK: when computing 3D >> descripors, most of the classes in charge of computing such >> descriptors will check that the input molecule actually has 3D >> coordinates, and throw an exception otherwise. > > Actually... there we have a different mechanism, and just return NA :) > In my experience, I have found both mecanism: some descriptors return NaN values (while the getException() method returns null), and others throws exceptions (in particular when they detect missing 3D coordinates). -- Vincent Le Guilloux Phd Student - ICOA - UMR CNRS 6005 Div. of chemoinformatic and molecular modeling. University of Orléans Phone: ++33 2 38 49 45 77 Fax : ++33 2 38 41 72 81 -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hello, On Jul 06, Vincent Le Guilloux wrote: > I would also roughly go to the Nina's solution, with a strong > agreement with Rajarshi. Just a few additional word to enrich this > interesting discussion: I also like that suggestion. > Too much exceptions handling / types usually gives verbose code (JAVA > is verbose enough hu... ;)), endless try/catch at every level of the > code, and bad performances. This reminds me the old debate about checked versus unchecked exceptions. There is a good summary about this topic: http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html One approach would be to have both checked and unchecked exceptions in the CDK API. Checked exceptions are used only for cases where the programmer has an obvios way for recovering the exceptional situation. The rest are runtime exceptions (could inherit from CdkRuntimeException). I've observed that checked exceptions in code are rarely handled, they are usually rethrown, logged, or swallowed. Best wishes, Sulev -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Wed, Jul 6, 2011 at 2:40 PM, Vincent Le Guilloux wrote: > I would also roughly go to the Nina's solution, with a strong > agreement with Rajarshi. Just a few additional word to enrich this > interesting discussion: Agreed. We'll have to aggregate the common types... I like the suggested CDKFormatException and CDKInputException, for example. I guess we'll also have CDKMissingInformationException. That should be granular enough. > Too much exceptions handling / types usually gives verbose code (JAVA > is verbose enough hu... ;)), endless try/catch at every level of the > code, and bad performances. That makes this perhaps good timing, as Java7 has "multicatch": http://bugs.sun.com/view_bug.do?bug_id=6943289 > Let's take a concrete example in the CDK: when computing 3D > descripors, most of the classes in charge of computing such > descriptors will check that the input molecule actually has 3D > coordinates, and throw an exception otherwise. Actually... there we have a different mechanism, and just return NA :) > In my opinion, this way of catching errors at such a low level is, > among others, a waste of CPU time. Let's suppose I read a molecule, > and I want to compute all 3D descriptors available in the CDK. How > many times the > 3D coordinates verification will be performed ? Probably it would have > been a good idea to check this before (up to the user then) it makes > much more sense imho :) Yes, that's why I mentioned that complementary rule that we must have matching CDK APIs to see if we can expect that exception to happen. For missing information this is easy. > Anyway, I think one have to be carefull about these things. Too much > code, too much check... render the final program harder to read / > understand, and computationally inefficient. > > I know, that's easy to say... but still :) We'll get there :) 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
I would also roughly go to the Nina's solution, with a strong agreement with Rajarshi. Just a few additional word to enrich this interesting discussion: Too much exceptions handling / types usually gives verbose code (JAVA is verbose enough hu... ;)), endless try/catch at every level of the code, and bad performances. Sometimes, the message comming from an exception is just good enough, because you can't actually do anything more that just showing the message to the end user / developper. A specific class will be usefull only if you can do something specific to overcome the problem within the program itself. More generally, I think the low-level functionalities of a program should assume that the input data are correct, and if not... well, the mistake goes to the user / developper :). In other words, the main exception handling should be performed at the highest level possible (e.g. GUI, or when reading data). Let's take a concrete example in the CDK: when computing 3D descripors, most of the classes in charge of computing such descriptors will check that the input molecule actually has 3D coordinates, and throw an exception otherwise. In my opinion, this way of catching errors at such a low level is, among others, a waste of CPU time. Let's suppose I read a molecule, and I want to compute all 3D descriptors available in the CDK. How many times the 3D coordinates verification will be performed ? Probably it would have been a good idea to check this before (up to the user then) it makes much more sense imho :) Anyway, I think one have to be carefull about these things. Too much code, too much check... render the final program harder to read / understand, and computationally inefficient. I know, that's easy to say... but still :) Vincent -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On 6 July 2011 15:26, Syed Asad Rahman 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 > > wrote: > >> > >> > >> On 6 July 2011 14:42, Rajarshi Guha 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
I too agree that exceptions should be problem related rather than module related. Asad On 6 Jul 2011, at 13:22, Rajarshi Guha wrote: > On Wed, Jul 6, 2011 at 7:50 AM, Nina Jeliazkova > wrote: >> >> >> On 6 July 2011 14:42, Rajarshi Guha 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
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 wrote: > > > On 6 July 2011 14:42, Rajarshi Guha 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 t
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
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 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/l
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Wed, Jul 6, 2011 at 7:50 AM, Nina Jeliazkova wrote: > > > On 6 July 2011 14:42, Rajarshi Guha 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On 6 July 2011 14:42, Rajarshi Guha 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
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 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hi Egon, I also support Nina's idea: - CDKException should be a root of all other CDK-specific exceptions. - The use of self-explanatory exceptions like NoSuchAtomTypeException is very welcomed, but in case there is no proper exception, throwing CDKException+message is fine. - Using IllegalArgumentException in proper context is absolutely fine. JavaDoc should mention that this exception is thrown when passed arguments do not meet certain constraints. On 06.07.2011 12:35, Nina Jeliazkova wrote: > Hello Egon, > > 1) and 2) are not mutually exclusive. > > My preference would be for 1) CDKException but combined with 2) > CDKException subclasses , e.g. NoSuchAtomTypeException should extend > CDKException class. This will leave a freedom for the code to catch > the top level or the more specific exception. > > Dropping CDK specific exceptions and sticking to 3) only , will likely > complicate troubleshooting in more complex environment, as a generic > Java exception might come from elsewhere, and will be harder work to > blame the CDK code in case of failure ;) > > Regards, > Nina -- With best regards, Dmitry -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Wed, Jul 6, 2011 at 12:51 PM, Jules Kerssemakers wrote: > 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. Interesting you bring this up. Exceptions should not be used for code flow. I guess this must be part of this design: for every CDKException (or subclass) we throw, we must have an API that allows checking if the required condition is fulfilled. 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
On Wed, Jul 6, 2011 at 12:35 PM, Nina Jeliazkova wrote: > On 6 July 2011 13:06, Egon Willighagen wrote: > 1) and 2) are not mutually exclusive. > My preference would be for 1) CDKException but combined with 2) CDKException > subclasses , e.g. NoSuchAtomTypeException should extend CDKException class. > This will leave a freedom for the code to catch the top level or the more > specific exception. Yeah, a root CDKExecption (abstract?) is a good idea. 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-user mailing list Cdk-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdk-user
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hi everyone, I would go for option 2 and subclass the CDKException - that way the exceptions are more informative. You can have different cases of illegal arguments being passed to a method and it's easier to handle these using custom exceptions than using the IllegalArgumentException with a different message. Also, IllegalArgumentException is an unchecked exception while CDKException is not. It may not be the best idea to mix these two. Kind regards, Christian On Wed, Jul 6, 2011 at 11:35 AM, Nina Jeliazkova wrote: > Hello Egon, > > On 6 July 2011 13:06, 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. > > 1) and 2) are not mutually exclusive. > My preference would be for 1) CDKException but combined with 2) CDKException > subclasses , e.g. NoSuchAtomTypeException should extend CDKException class. > This will leave a freedom for the code to catch the top level or the more > specific exception. > Dropping CDK specific exceptions and sticking to 3) only , will likely > complicate troubleshooting in more complex environment, as a generic Java > exception might come from elsewhere, and will be harder work to blame the > CDK code in case of failure ;) > Regards, > Nina > >> >> 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 > > -- 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
Re: [Cdk-user] [Cdk-devel] Exceptions again: three designs. What will we use in the next CDK series (1.6 or 2.0)?
Hello Egon, On 6 July 2011 13:06, 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. > 1) and 2) are not mutually exclusive. My preference would be for 1) CDKException but combined with 2) CDKException subclasses , e.g. NoSuchAtomTypeException should extend CDKException class. This will leave a freedom for the code to catch the top level or the more specific exception. Dropping CDK specific exceptions and sticking to 3) only , will likely complicate troubleshooting in more complex environment, as a generic Java exception might come from elsewhere, and will be harder work to blame the CDK code in case of failure ;) Regards, Nina > > 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
