I am trying to debug code that typically functions properly and has been in production for a while, but has some errors associated with particular case runs.
I have a class called "Guarantee", and a variable / object, "myDem", which is of that class. The class has an associated function called "NumberOfGuaranteeDays". The first image given below shows a Long variable called "numRows" being assigned to this function call on "myDem". When this assigment is made -- and, therefore, the "NumberOfGuaranteeDays" function is called -- I receive an Overflow error.
After the function call "NumberOfGuaranteeDays" is run, which is a fairly complex call with many sub-functions itself, then class attempts to terminate itself, and return the value (the number of days, which is an integer... in this case it's 32561). It is during this termination step and the assignment of "numRows" to the value 32561, when the error occurs.
Here I simply demonstrate that the very next step within the code, if I step through it, is where the error message is returned back to me.
Finally I wanted to provide "proof" that the value assigned to "numRows" is 32561, of type Integer, which can acceptably be assigned to a Long. Note in the far right in the watch part of the window, the value "res" is the value which is returned from the "NumberOfGuaranteeDays" call, which is then assigned to the variable "numRows".
As far as I can tell, there are only 2 possibilities for why a crash can be occurring:
There is an error in the attempt to terminate the class. I don't understand how this could lead to an "overflow" error, though.
There is an error in the assignment of the value calculated from "NumberOfGuaranteeDays" to the variable "numRows". This sort of assignment could potentially have an overflow, but not in this case. The return from "NumberOfGuaranteeDays", which is the "res" integer set at 32561, is assigned to "numRows", which is a Long.
So, since neither of these possibilities that I can imagine make sense, I figure there must be another possibility I cannot see. Thank you all in advance for the help!
I opted to put in cut & pasted images instead of writing as code because so much of what's critical to understanding the steps is seeing "proof" of where I am in the debugging stages. If actual code snippets would help, let me know.
Thank you!
Mike
Related
I have the following two lines of code:
Debug.Print Forms!DocLoader!DL_RowBox!DLR_FileName.Name
Debug.Print Forms!DocLoader!DL_RowBox.Form!DLR_FileName.Name
The second one, which I have seen recommended in almost every VBA reference, including the answer being suggested from SO as I type this, follows this structure:
Debug.Print Forms![Form Name]![Subform Control Name].Form![Control Name].Name
These two lines of code should produce the same result. However, the second, recommended syntax throws error 40036, "Application-defined or object-defined error" unless I am in design view. I cannot use it at runtime, but I have never seen this limitation mentioned in any of the reference documentation or forum posts I have looked at. The first line, using only default parameters, seems to work no matter the context.
With the second line, I have tried just about every combination of bang and period I can, and I have also tried enclosing field names in brackets, but the common denominator is that as soon as I reference ".Form" the application throws an error. Even something simple like ".Form.Caption" has thrown an error. So what I would like to know is:
Are there any other correct ways of referring to a subform's form properties, since I need these as well as its controls
Why would the first line execute correctly while the second, recommended one does not seem to work?
Running the compiler appears to have fixed the issue.
in PDI I've got the following structure
0_Metajob
1_Load_1
1_Load_2
1_SimpleEvaluation
1_Mail
As of now
1_Load_1 and 1_Load_2 are independent of each other. The second one will run, irrespective of the success of the first one. That is okay, I want it that way!
Issue
I want to have a counter that is incremented by one every time one of the single loads fails, i.e. in my example the counter can take the values 0, 1 or 2.
What do I need it for? Customer will receive a mail at the end of the metajob. The aforementioned value determines the subject of the mail, i.e. 0=everything fine, 1=so-so, 2=load totally failed!
Why not mailing within every single the Load-Job? I do that but without attaching the log-file because it is usually non-finished. Therefore the log-file is mailed with the mail that is sent when the Metajob is finished.
Tried
"Set a variable". Thought I can simply increment it with adding a one in the value field, i.e. "${VariableName}+1". Of course, this step is implementened within a fail path of each Load-Job.
However, it didn't work.
Would anyone mind helping me? I would appreciate that!
Set Variable doesn't do calculations, you'll need a Javascript step for that.
Fortunately, variables can be also be set within the Javascript step. This bit of code should go into each of the steps you put in place of the Set Variable steps:
var i = parseInt(parent_job.getVariable("Counter"),0);
i = i + 1;
parent_job.setVariable("Counter",i);
true;
This bit of code gets the variable "Counter" from the parent job and converts it to int, since all Pentaho variables are strings. Then it increments it and sets the job variable again. The "true" at the end is to ensure that the javascript step reports success to the main job.
IMPORTANT: This works roughly as you would expect in a Job. It will NOT in a transformation!
I'm working with legacy code and ran across something that I haven't been able to explain after several days of looking up tutorials and handbooks for GW Basic: a variable (P9%) is used in a comparison on line 530 (IF P9% <> 0) before the code would reach its definition on line 860. It's not a complex piece of code, only ~1200 lines total, so I am confident that I haven't missed any goto or gosub or anything that would reach 860 earlier than this comparison.
I am curious as to how this has been effecting the program as it runs. Most of my experience is with c++ where this sort of thing wouldn't compile, and if it did an unassigned variable could potentially contain anything that would fit, but I have no idea what kind of default assignment is given to a variable in Basic.
It has been many years since I wrote much in gwbasic!
If I remember correctly the variable is assigned a zero value in that case. Gwbasic (and Qbasic I think) assigns a default value to all variables when first referenced, this is usually zero or the empty string for a string variable.
Interestingly when creating an array using the DIM statement, all the items in the array are also initialised this way.
Even with this mechanism it is usually better to initialise a variable, just to be clear what is happening.
Many programmers of the era writing for gwbasic omitted as much as they could to minimise the amount of memory used by the program instructions so they had more for other stuff. So that may be why it's not initialised.
This might be an odd question, but I'm looking for a word to use in a function name. I'm normally good at coming up with succinct, meaningful function names, but this one has me stumped so I thought I'd appeal for help.
The function will take some desired state as an argument and compare it to the current state. If no change is needed, the function will exit normally without doing anything. Otherwise, the function will take some action to achieve the desired state.
For example, if wanted to make sure the front door was closed, i might say:
my_house.<something>_front_door('closed')
What word or term should use in place of the something? I'd like it to be short, readable, and minimize the astonishment factor.
A couple clarifying points...
I would want someone calling the function to intuitively know they didn't need to wrap the function an 'if' that checks the current state. For example, this would be bad:
if my_house.front_door_is_open():
my_house.<something>_front_door('closed')
Also, they should know that the function won't throw an exception if the desired state matches the current state. So this should never happen:
try:
my_house.<something>_front_door('closed')
except DoorWasAlreadyClosedException:
pass
Here are some options I've considered:
my_house.set_front_door('closed')
my_house.setne_front_door('closed') # ne=not equal, from the setne x86 instruction
my_house.ensure_front_door('closed')
my_house.configure_front_door('closed')
my_house.update_front_door('closed')
my_house.make_front_door('closed')
my_house.remediate_front_door('closed')
And I'm open to other forms, but most I've thought of don't improve readability. Such as...
my_house.ensure_front_door_is('closed')
my_house.conditionally_update_front_door('closed')
my_house.change_front_door_if_needed('closed')
Thanks for any input!
I would use "ensure" as its succinct, descriptive and to the point:
EnsureCustomerExists(CustomerID)
EnsureDoorState(DoorStates.Closed)
EnsureUserInterface(GUIStates.Disabled)
Interesting question!
From the info that you have supplied, it seems to me that setstate (or simply set, if you are setting other things than states) would be fine, though ensure is good if you want to really emphasize the redundancy of an if.
To me it is however perfectly intuitive that setting a state does not throw an exception, or require an if. Think of setting the state of any other variable:
In C:
int i;
i = 5; // Would you expect this to throw an exception if i was already 5?
// Would you write
if (i != 5)
i = 5;
// ?
Also it only takes about one sentence to document this behaviour:
The function does nothing if the
current state equals the requested
state.
EDIT: Actually, thinking about it, if it is really important to you (for some reason) that the user is not confused about this, I would in fact pick ensure (or some other non-standard name). Why? Because as a user, a name like that would make me scratch my head a bit and look up the documentation ("This is more than just an ordinary set-function, apparently").
EDIT 2: Only you know how you design your programs, and which function name fits in best. From what you are saying, it seems like your setting functions sometimes throw exceptions, and you need to name a setting function that doesn't - e.g. set_missile_target. If that is the case, I think you should consider the set_if, set_when, set_cond or cond_set names. Which one would kind of depend on the rest of your code. I would also add that one line of documentation (or two, if you're generous), which clarifies the whole thing.
For example:
// Sets missile target if current target is not already the requested target,
// in which case it does nothing. No exceptions are thrown.
function cond_set_missile_target ()
or function cond_set_MissileTarget ()
or function condSet_MissileTarget ()
or function condSetMissileTarget ()
ensure is not so bad, but to me it implies only that there is additional logic required to set the state (e.g. multiple states tied together, or other complications). It helps to make the user avoid adding unnecessary ifs, but it does not help much with the exception issue. I would expect an ensure function to throw an exception sooner than a set function, since the ensure function clearly has more responsibilities for, well, ensuring that this setting operation is in fact done right.
I'd go for ensure for the function you describe. I'd also use camelCase, but I suppose you may be in a language that prefers underscores.
You could always document (shock!) your API so that others don't make the mistakes you describe.
I have a complex iterative spreadsheet in which I want to use a UDF to calculate the heat transfer coefficient of a heat exchanger. The function has 5 arguments (2 strings and 3 doubles). The strings and 1 double pass just fine. The remaining two don't seem to go through at all. A watch on problematic arguments shows them to be equal to zero. I tried redefining the arguments as variants, and then I can find the value I want in the "value2" field. However, as soon as I try to access it (via varName.Value2) it disappears (the watch suddenly lists the field as "Empty").
The cells passed into the function for the problematic arguments are heavily dependent on the rest of the spreadsheet, and their value changes almost every iteration.
Has anyone seen this before and know of a workaround?
I use UDFs with +6 input variables (the standard types as well as variants), and I have noticed (this is my interpreation of what happens) that sometimes the excel calc engine tries to trigger the UDF before all the input values become calced and available. From the debug view this is seen as the function making "false starts" and stopping to execute mid-procedure (thread is lost) so debugging-wise it shows a strange behaviour.
However, when written into a cell the function still calculates and returns correctly.