Hi everyone,
Does anyone know of a way to get the full printout of a run-time error (with all the stack breakdown), but without it breaking the script-run?
I know all about openLog, flushLog, closeLog, try/catch/throw, etc.
The thing is, if you do:
openLog <fileName>
try (…code…) catch (<errorStringVariable> = getCurrentException())
closeLog()
Then the script will continue, but all you get in the errorStringVariable is the error itself, without all the stack-description, and if you do:
openLog <fileName>
…code…
closeLog()
and the code crashes, it won’t continue, and wont even necessarily flush the stack into the log file (as it won’t even get to the closeLog() line) .
I’ve serched the help, then the forums, and only found this:
http://forums.cgsociety.org/showthread.php?f=98&t=316311
Which does not address this issue.
I know that if you do:
try(
…code…
try (…code…) catch (throw())
…code…
) catch(errorStringVariable> = getCurrentException())
then the inner catch will throw the entire error onto the exterior catch, but the getCurrentException there will still filter-out only the error itself and not the stack-breakdown, and again, if I enclose all this within an openLog/closeLog statements, they still won’t output the stack-breakdown into the log-file, as it won’t be printed in the listener.
err… How can I get the best of both??
Continuing the run-time without breaking,
but still getting the stack-breakdow into a file, so I can then e-mail it to myself?
I know some people use the maxScript debugger, I can maybe do something within via script, but how would that accomplish what I need?
Thanks to anyone who figures this out…
Ok, I found some more stuff, but it still not exactly what I need.
If you do:
try(
…code…
) catch(
<file Handle> = createFile <file Path>
stack to:<file Handle>
close <file Handle>
)
Then you get the stack info, but only of the catch frame.
If you do:
try(
…code…
if not <predicate> do (
<file Handle> = createFile <file Path>
stack to:<file Handle>
close <file Handle>
throw()
)
…code…
) catch()
Then you can get the stack of the code that crashed, but even then, you don’t get the deeper frames then the current one, if what caused the crash was within a called function. Also, it’s only useful if you check for something specific in the code, not useful for crashes that you don’t anticipate.
And then there’s “Assert <predicate> showStack:true”, but it’s only supported from max 2010, and even then it’s not useful as in addition to all limitations in the above example, it doesn’t throw an exception, which is good if you always want to continue anyways, but not good if you want to do something else. You can only brake it into the debugger, but then the script stops, you cannot bypass the current stack-frame with a catched exception that continues the code outside the current frame through an alternative route. It seems as though it was meant for actual debugging, and not for general-use error-handling.
Any thoughts??
Hi dudes, anyone has an idea about this issue?
(Sorry for the bump-up, but I can’t think of another way to get new people to see it…)
to me it seams like you spent to much time on this problem. All that you need to know is why the code was crashed, how fatally is was, where it was happened, and what were the states of some variables at that moment.
Am I right? Do everything yourself with try(), catch(), throw(), and getCurrentException(). Define your own list of variables inside the code to monitor them, and print their states on a catch happening. I would do this way.
Thanks for replying denis, and I would have agreed completely had it been a matter of a single tool. What I’m looking for is something that can be applied systematically, and for that, if going by what you said, I would have to go through every block of code (or at the very least every tool) and implement that specifically. That could take forever…
I’ve already gone quite ahead in the systematic-direction since I last posted hear, which simplifies what you are suggesting: I wrote a struct that contains function that deal with error-handling, one of which writes the current-stack into a file (after some cleanup), and only then throws the exception (if asked to by a parameter). This way I can get the stack going upward (and not just the current exception) while also providing that function with a more coherent error string (describing logically what’s wrong), and I don’t need to query each variable in the block (or it’s “upper”/“calling” blocks) manually.
The thing is, the stack only goes “upward” to the block it is invoked from, and not down to the specific cause for the current block (frame) to dysfunction. I get only an upward-half snapshot of the causality-chain, which is unhelpful when the root-cause is deeper than this block (a result of a bug within a function, that is called through another function … that one of the lines in the current block calls to).
Not to mention I have to manually place a call to this error-handling struct within each block I want to monitor (basically for every value being returned from an external function).
The thing I like with the stack that is presented in the listener when a script crashes (without try/catch), is that it includes the “entire” stack (the whole depth), down to the lasts value that generated the problem.
I’m looking for a way to get “this” kind of stack (as a value), without having the script crashing.