PDA

View Full Version : When to deal with errors?


Leionaaad
09-15-2010, 09:50 PM
You write a few generalised scripts, you source it in others, then everything builds up in hierarchical manner. Right?
Right.
Where to check for errors?
In the lowest tier of scripts, which are sourced later over ad over again, or in the top level, the ones actually used by the user and assuming every argument gets where it should? I assume checking for errors over and over again would be unnecessary.

What is the general practice in this regard?

Morganism
09-16-2010, 12:51 AM
In the script editor, under History, turn on Show Stack Trace. That will pop up a little window when you get an error that should help you track it down by showing you all the line numbers and files involved. Also make sure you have Line Numbers in Errors turned on.


EDIT:
Whoops, I misunderstood your question.

In MEL there's no great way to manage error checking like you're asking, I tend to leave error checking out of my low level scripts for speed and simplicity, with the thought that if they're erroring, there's probably something wrong upstream, because no one should be calling them manually. For some small scripts, if they don't have a return value, you can have it return true or false depending on if it was successful, and then use that value to manage error checking in the parent script.

To be honest I don't really know the best way to do it, but if you put error checking in every little procedure that's going to take up a huge chunk of code, and a lot of it is going to be redundant. Plus think how often it will be called, if you have a procedure that normally gets called in a loop, it might be silly and slow to check for errors on each iteration.

mduvekot
09-16-2010, 01:54 AM
It's not always a matter of choice, is it?

If I were to make a mistake like

proc float add2nums (float $x, float $y) {
return $x + $y;
}

add2nums "foo" "bar";

there's only one place for me to check is there?

Leionaaad
09-16-2010, 09:22 AM
Thanks for the quick response

It's not always a matter of choice, is it?

If I were to make a mistake like

proc float add2nums (float $x, float $y) {
return $x + $y;
}

add2nums "foo" "bar";

there's only one place for me to check is there?

Yes, you're right, but you can't put everything in one big procedure can you? I am speaking about packages with several dozens of procedures.

NaughtyNathan
09-16-2010, 09:47 AM
ideally you should put error-checking in every part of your scripts, but knowing when this is absolutely necessary and totally irrelevant (and all stages inbetween) comes mainly with practice and experience, I wouldn't have thought you could boil it down to a simple general rule...

For example, Lets say you have a sub-proc that takes in a single vector (a RGB colour) and returns an adjusted colour vector. You could make the first line of this proc an error check to make sure the vector is a valid colour, or you could check this before every line in the main code that calls this function. If you call it more than a couple of times you would think it would make more sense to add the error-checking in the proc right? well, if the cause of the error, or the issue which caused the error was something that your main proc needed to act upon, error-checking inside the proc may be pointless as the main proc still needs to check stuff itself (as MEL cannot return different types).

Finally, depending on your code it may be feasible that an inncorrect RGB vector is "impossible", in which case none of the error-checking is necessary here.

Knowing how to handle all this comes with experience, and a lot of such code decisions you make are down to personal preference anyway..!

:nathaN

fezz
09-16-2010, 05:52 PM
I'm working on a particularly large script project right now and one thing that I've found helpful is to put in debug statements at key points in a lot of my scripts, and use an optionVar to trigger it:

if (`optionVar -q sys_debug`){
print (">> DEBUG: procName: "+$output+"\n");
}

I have a shelf button that toggles that optionVar on or off, so if something isn't behaving properly, I turn it on and get a running output of everything that's happening. Saves me a lot of time and is a lot quicker than commenting out large numbers of print statements.

Leionaaad
09-16-2010, 09:25 PM
Thanks again for the replies.
I'm working on a particularly large script project right now and one thing that I've found helpful is to put in debug statements at key points in a lot of my scripts, and use an optionVar to trigger it:

Interesting idea... don't understand it completely, but I will look into it in detail.

My main problem is that I work a lot based on selections. There are situation when I need exactly one object to be selected, or exactly two. These were the main issues until now, along with some others, these are easy to miss.

NaughtyNathan
09-16-2010, 09:45 PM
hey Fezz, I do a similar thing, but in a sligtly different way... make a proc called dprint (or debug or whatever) that checks the optionVar then prints.. then all your code looks even shorter and neater:

proc dprint(string $print)
{
if (`optionVar -q sys_debug`) print ("// > DEBUG: "+$print+"\n");
}

MEL code .....
MEL code .....
dprint "some debug text";
MEL code .....
dprint "another debug message... etc...";
MEL code .....
and you don't get a lot of if {...} cluttering your code!

Leonard, if you are expecting x objects selected then yes, that is one place where you should definitely error-check, but I think you only need to check once at the start, before you call any procs, then your procs can probably just assume the correct inputs.

:nathaN

fezz
09-17-2010, 01:28 AM
hey Fezz, I do a similar thing, but in a sligtly different way... make a proc called dprint (or debug or whatever) that checks the optionVar then prints.. then all your code looks even shorter and neater:

proc dprint(string $print)
{
if (`optionVar -q sys_debug`) print ("// > DEBUG: "+$print+"\n");
}

MEL code .....
MEL code .....
dprint "some debug text";
MEL code .....
dprint "another debug message... etc...";
MEL code .....
and you don't get a lot of if {...} cluttering your code!

Leonard, if you are expecting x objects selected then yes, that is one place where you should definitely error-check, but I think you only need to check once at the start, before you call any procs, then your procs can probably just assume the correct inputs.

:nathaN

See, this is why I love CGTalk:applause:

Thanks again for the replies.
Interesting idea... don't understand it completely, but I will look into it in detail.


My button looks something like this:

{
if (!`optionVar -q sys_debug`){
print ">> turning debugging on\n";
optionVar -iv sys_debug 1;
} else {
print ">> turning debugging off\n";
optionVar -rm sys_debug;
}
}

Basically you check to see if the variable is set in the system and if it isn't, set it... else remove it.

CGTalk Moderation
09-17-2010, 01:28 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.