Le mercredi 07 octobre 2009 à 17:29 -0400, houtan a écrit :
I have encountered a couple of problems coding up the Expectation operator which would be alleviated if you could answer the following questions:
- In DataTree::AddVariable(int symb_id, int lag), why is there an
"assert(lag==0);" at the beginning of this file and how can we add variables to the datatree with leads/lags?
This is the default implementation of that method, used in StaticModel, to be sure that we have only variables at the current period. Since this method is declared virtual, it is overloaded in DynamicModel::AddVariable() by another implementation which allows leads/lags.
- I am a bit confused as to how negative numerial constants should be
stored in the datatree. Should they be stored as a unaryOpNode of type oUminus pointing to a positive numConstNode (as is the case for MinusOne and MinusIninity)? Or should they be stored as a potentially negative number as in ParsingDriver::add_constant(string *constant)?
First case:
UnaryOpNode(oUminus) -> NumConstNode(>=0)
- Is there a guideline for which types of potential errors to handle
nicely (by printing a message to cerr and exiting) and which ones to simply allow to pass by? Say, for example (as I have not coded this fully yet), I would like to look up an oExpectation BinaryOpNode in the subst_table when replacing the oExpectation BinaryOpNode with a Variable node pointing to the associated auxiliary variable. This auxiliary variable would be provided if I had correctly inserted everything into the subst_table. If, on the other hand, there is a bug in my code, it will not return this and will break during processing. Though this will be tested for after the Expectation operator has been implemented, you can see that there are many such situations that could potentially arise. Hence, I was wondering if you have any advice as to when one should test for errors in processing (and print appropriate error messages) and when one should assume that everything has worked correctly. I hope this is clear and that I have not been too long-winded.
The best practice is to use assert() for debugging purposes: it emphasizes the conditions which are supposed to be met at some point in the code, so this enhances the readability of the code. The idea is that when the condition is not satisfied, there is a bug in the code: then the assert() will display an error message with the source filename and line number, and exit the program.
The use of cerr followed by an exit is appropriate for messages which indicate an error coming from the user.
However I don't always follow this practice and use cerr/exit for debugging purposes at some places, but this is something which we should better avoid.
Best,