I'm finding it very difficult to develop with PyClips, because it appears to replace useful error messages giving my Clips with an generic "syntax error" message. This makes debugging very laborious and practically impossible when using PyClips.
Consider the following example. I wrote a very large expression, which contained the multiplication operator, but I mistakenly forgot to add the second argument. Instead of simply telling I was missing an argument, PyClips told me there was a syntax error. What should have taken me 2 seconds to correct, took me 5 minutes to correct as I hunted through my large expression, looking for the mistake.
Here's a condensed version:
CLIPS> (defrule myrule "" (myfact 123) => (bind ?prob (* (min 1 2))))
[ARGACCES4] Function * expected at least 2 argument(s)
(defrule MAIN::myrule ""
(bind ?prob (* (min 1 2))
>>> import clips
>>> clips.BuildRule('myrule','(myfact 123)','(bind ?prob (* (min 1 2)))','')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.6/dist-packages/clips/_clips_wrap.py", line 2839, in BuildRule
_clips.ClipsError: C08: syntax error, or unable to parse expression
How can I get PyClips to give me the *real* error thrown by Clips?
Of course, since CLIPS uses "pseudo files" (and not codes, as PyCLIPS, nor it "throws" exception-like objects) to report about errors, you will have to read the messages yourself from the TraceStream and the ErrorStream: they report the exact messages that CLIPS reports. Usually you need to read the last line, sometimes you'll have to take some more lines into consideration.
However, an even better way to debug a PyCLIPS program involves the use of a dribble file.
Thanks. Having to parse an error log isn't ideal, but it's enough for me to write my own wrapper to generate a more descriptive Exception object.
Indeed, if you just read the ErrorStream (after a suspicious operation) you get a string in square brackets (which can function as an error code) and then a "more descriptive" error text. Unfortunately this is the way CLIPS reports back, instead of actually returning an error code for situation that might involve syntax errors. But: is it the correct approach to have to handle CLIPS syntax errors dynamically? Wouldn't it be a better option to force construction (if it's dynamically built) of valid CLIPS code? After all, this is the approach suggested in the APG as well.
That's true. However, I'm not sure that's better than handling errors dynamically. For example, in order to have caught the error above, my code would have first had to know that the multiplication operator takes at least two arguments. I could certainly write code check this constraint beforehand, but I'd eventually have to do this for every built-in Clips function. This strikes me as redundant, since Clips already has these checks built-in, so why not let Clips tell me when something's broken?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.