PDA

View Full Version : reporting methods?


3rd Dimentia
07-07-2011, 09:22 AM
I would like to hear people's thoughts on reporting methods in scripts. When I say reporting, I mean recording and outputting whether elements of the script needed to be run and if they did, did they successfully complete the task? I have 2 main methods I use currently.

Test every single act manually to see if it returned the value that it was supposed to be set to. Obviously this can be quite laborious.

Use try and catch around chunks of code to get a general idea if that area of code executed without error.

Any other ideas or methods that people have found useful?

Cheers,

Cg.

3rd Dimentia
07-08-2011, 04:32 AM
Surely I'm not the only person around here that does error/success checking/reporting in their scripts. Or is it that people just don't want to share their techniques? I'm keen on discussion about the pros and cons of the 2 ways that I mentioned. I know try/catch can slow things down. And the other way can sometimes mean adding more code to do the error checking than existed to get the task done. Often my script's actual functionality is a very small percentage of the code and the rest is error checking/idiot proofing. Is that normal? I've also been wondering if there was a way to decouple the error checking so that it was handled by a function rather than being intertwined with every bit of code that tries to do something. But obviously I haven't come up with anything that tidy yet.

With both of the error checking methods I mention, I use the same method of storing the output in a string/s that get built as the script executes and then outputs that at the end either to the listener or a messagebox.

I would have thought that a lot of people would probably have something to gain from a discussion on this topic. Surely some of you have thoughts/experiences to share?

Cheers,

Cg.

denisT
07-08-2011, 04:44 AM
do you really hate bugs, don't you? is it acarophobia or kind? ;)
do you like to know how to treat it?

3rd Dimentia
07-08-2011, 04:50 AM
Oh come on Denis, I know you've got to have some thoughts on this topic other than bad puns. Why won't you engage in a discussion? Are your methods too secret? :bowdown:

Cg.

denisT
07-08-2011, 05:42 AM
Oh come on Denis, I know you've got to have some thoughts on this topic other than bad puns. Why won't you engage in a discussion? Are your methods too secret? :bowdown:

Cg.
i hate bugs.
i can ... hmm... how to say... accept my own bugs but i am definitely hysterical about anybody's else. :)

first of all - forget about mxs debugger. it's most useless tool in max studio. i might be wrong but the debugger is not just useless, it's harmful.

simply use print or format to get an interim result.
use try/catch if you know for sure that the case of a failure is not your own.

3rd Dimentia
07-08-2011, 06:04 AM
I do use format to output the state of stuff as I'm writing/debugging a script. But I'm talking about covering for unforeseen circumstances in the normal usage of the tool by non-maxscripty users. When, for some unusual reason the code that normally works perfectly does not successfully execute. So when something like that does happen, the script will report it with a pre-planned response rather than "crash" out giving the user a non-friendly maxscript error. Or is that what you would also call bug reporting?

Or am I just obsessing over something that no one else cares about?

denisT
07-08-2011, 06:19 AM
I do use format to output the state of stuff as I'm writing/debugging a script. But I'm talking about covering for unforeseen circumstances in the normal usage of the tool by non-maxscripty users. When, for some unusual reason the code that normally works perfectly does not successfully execute. So when something like that does happen, the script will report it with a pre-planned response rather than "crash" out giving the user a non-friendly maxscript error. Or is that what you would also call bug reporting?

Or am I just obsessing over something that no one else cares about?

unfortunately there is no an easy and clear way of mxs debugging. try/catch system just can report that you've shitted yourself.

3rd Dimentia
07-08-2011, 06:30 AM
unfortunately there is no an easy and clear way of mxs debugging. try/catch system just can report that you've shitted yourself.

Yes I understand there is no clear, easy way to do this. That's why I'm trying to have a discussion on the more unclear/complex ways to go about this.

denisT
07-08-2011, 06:32 AM
... am I just obsessing over something that no one else cares about?

any tools developer has to care about his domestic user

Bobo
07-08-2011, 06:39 AM
It is very difficult to think of every possible way a script could be executed and crashed, but there are certain things you could get into habit of adding to deal with the obvious.

If you assume that your code is relatively bug-free at its core, you should concentrate on the user interaction first. Whenever you allow the user to make a decision via the UI, you should add precautions to ensure the result was as expected.
For example, whenever you let the user pick a scene object, make sure the result was valid via isValidNode(). If the object is expected to be of a specific class, implement a filter function to ensure the user cannot even see the wrong object types.
If you are expecting a GeometryClass object, also make sure it has a valid mesh - in other words, always filter for (classof theObject != TargetObject).
If you ask the user to pick a file from disk, make sure the result != undefined (which happens when the user presses Cancel instead of picking a file).
If the script depends on certain objects being selected in the scene, if you are running a MacroScript, implement on isEnabled return () handler to disable the ActionItem if the current selection does not make sense, or if it is a Dialog, either disable the controls when the selection makes no sense, or report to the user things were not as expected when he presses a button.

Once you have these general precautions at UI level, anything else that fails is your fault and you could handle with some form of try()catch() or assert() handling, or just let the script crash. If you are sure the users cannot take a wrong turn while using the UI, you can assume that it was your bug when they come running to report a crash.

I am sure you know all this. Note that Max 2012 added a large number of assert functions to ensure validity of values, but since I tend to work on scripts that should run on Max 9 to 2012, I don't even think of using the latest tech for these things. And I have never used the Debugger either.

One thing I tried to implement in some of the larger tools back at Prime Focus was solid and very verbose logging (the same is available in the Max To Deadline submitter). Basically, I create and keep on appending to a text file with today's date every time something good or bad happens inside the script logic. If a user comes with a problem (not necessarily a crash, but unexpected result or behavior), I go and open the current log file and see what he did and what he got. I had log files gathered for YEARS from some of these tools, so we could go back and trace all steps of the tool's usage by any user. I also output performance info (how long did it take to run every function) to help with profiling and compare performance after a bigger change to the code. This logging was stored on the local drive to avoid network issues, but one TD at PF actually implemented centralized logging so all logs were stored on a network drive and could be processed at once. I felt that was too Big Brother, but the bottom line is that the more you can see of what users have been doing with the tool while you weren't around, the easier it would be to figure out what went wrong when they come to you with an error...

my 2 cents.

denisT
07-08-2011, 06:52 AM
Yes I understand there is no clear, easy way to do this. That's why I'm trying to have a discussion on the more unclear/complex ways to go about this.

the number ONE rule is - DON'T conceal your imperfection. i'm 15 years in MAX business but every day i start with Bobo's mxs help.

-- don't hide exceptions.
-- ask your user to report any bug with full description.
-- open the code.
...

sorry but i don't know any other ways.

3rd Dimentia
07-08-2011, 08:02 AM
Thanks Bobo for taking the time to share your experience. Most of what you mention I already do. Having bought TheMatrixExplained, I think I picked up some good habits early on. But you have definitely given me some new things to think about and try. Especially the logging system. Awesome.

Cheers,

Cg.

CGTalk Moderation
07-08-2011, 08:02 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.