Login | Register
My pages Projects Community openCollabNet

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

maxq
Discussion topic

Hide all messages in topic

All messages in topic

Re: [maxq-dev] Error/exception handling

Author hdara at primavera dot com
Full name hdara at primavera dot com
Date 2004-09-20 14:16:33 PDT
Message Oliver Bock <oliver at g7 dot org> wrote on 09/20/2004 02:11:24 PM:

> Errors that originate in Java code should continue to display as a Java
> stack trace because we now only catch PyException. Other
> exception/errors should be reported in the usual way. Therefore I hope
> we need do nothing.
>
>
> Oliver
>

Right, but occassionally, the stack trace for the script errors could be
useful too, but no big deal. Generally, when I modify an existing
functionality, I throw in a configuration property to switch to the old
behavior, unless it is a lot of work.

Just my 2c.
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

Re: [maxq-dev] Error/exception handling

Author oliverbock
Full name Oliver Bock
Date 2004-09-20 14:11:24 PDT
Message Errors that originate in Java code should continue to display as a Java
stack trace because we now only catch PyException. Other
exception/errors should be reported in the usual way. Therefore I hope
we need do nothing.


    Oliver

--
On 21/09/2004, at 03:13, hdara at primavera dot com wrote:

> 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
>


--------------------​--------------------​--------------------​---------
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

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

[maxq-dev] Error/exception handling

Author oliverbock
Full name Oliver Bock
Date 2004-09-19 22:50:29 PDT
Message 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


--------------------​--------------------​--------------------​---------
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
Messages per page: