Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [maxq-dev] Error/exception handling

maxq
Discussion topic

Back to topic list

Re: [maxq-dev] Error/exception handling

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-09-20 10:13:24 PDT
Message Oliver Bock <oliver at g7 dot org> wrote on 09/19/2004 10:50:29 PM:

> Error handling in maxq is currently a mess. If your script fails then
> you see multiple stack traces showing maxq, JUnit and Jython internals.
> I think users will normally prefer to see just the python-style stack
> trace. It will tell them what line of the script failed.
>
> The large, ugly error outputs occur because:
>
> 1. JUnit-style failures (e.g. assertEquals()) throw exceptions in the
> Java code. When this occurs you see both the Java stack and the Python
> stack, when really you only want to see the Python stack.
>
> 2. Exceptions and Errors thrown during the tests are caught by JUnit
> and then rethrown by HttpTestCase.Run(). This adds another stack
> trace.
>
> 3. We print these rethrown stack traces in Main.runTests().
>
> I think this state of affairs will must repel a lot of new users
> because script failures look a lot worse than they are.
>
> So, what can we do?
>
> 1. When running from within the IDE or from the maxq command line, no
> JUnit test harness is actually in place. Therefore there is no need to
> run JUnit to invoke our tests. We can call setUp(), runTest() and
> tearDown() much more cleanly without it. (People can still run their
> tests in JUnit harnesses as before.)
>
> 2. Raise errors in Jython code, not from Java. A simple "raise 'x
> failed'" is sufficient and yields much simpler Python-only stack
> traces. JUnit will still catch and display Java exceptions so little
> is lost.
>
> (As far as I can tell, the only way you could run scripts as proper
> JUnit tests is to put maxq.jar in your CLASSPATH, compile the tests
> using jythonc and then run them as normal Java test classes. Does
> anyone actually use JUnit with maxq?)
>
> I have already implemented the first point, and am converting my
> scripts to use the second. Thoughts?
>
>
> Oliver

I agree, a simple python trace will be more desirable than seeing all the
internal stack. I can't see a reason why seeing those exceptions will be
useful to the user. However, the exceptions could be useful to debug maxq
itself, so I would recommend using a property to control the behavior (the
python only stack being the default).

Thanks,
Hari

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at maxq dot tigris dot org
For additional commands, e-mail: dev-help at maxq dot tigris dot org

« Previous message in topic | 2 of 4 | Next message in topic »

Messages

Show all messages in topic

[maxq-dev] Error/exception handling oliverbock Oliver Bock 2004-09-19 22:50:29 PDT
     Re: [maxq-dev] Error/exception handling hdara at primavera dot com hdara at primavera dot com 2004-09-20 10:13:24 PDT
         Re: [maxq-dev] Error/exception handling oliverbock Oliver Bock 2004-09-20 14:11:24 PDT
             Re: [maxq-dev] Error/exception handling hdara at primavera dot com hdara at primavera dot com 2004-09-20 14:16:33 PDT
Messages per page: