[Kss-devel] Error demo

Balazs Ree ree at ree.hu
Fri Dec 7 08:34:10 CET 2007


On Fri, 07 Dec 2007 07:19:54 +0100, Balazs Ree wrote:

> On Fri, 07 Dec 2007 01:27:32 +0100, Godefroid Chapelle wrote:
> 
>> PS : Balazs, can you check that the error_handling test does what it is
>> supposed to do : iow no handling of the two first buttons of the second
>> row.
> 
> That's ok, the first two buttons are unhandled on purpose. They can be
> used to test what happens in case of unhandled server side error. This
> is both interesting in development (logging) and production mode (well,
> they are invisible in this case, and we will need to figure out
> something for this).
> 
> I may add some message to clarify this.

Oops, I am sorry. Wrong info. The correct answer should have been: the 
first two buttons on the second row are although handled, but they do not 
cause an error. 


So this is the full pattern:


First row unhandled:
no_error    no_commands  server_exception  server_explicit_error
          
Second row handled:
no_error    no_commands  server_exception  server_explicit_error
          


The meaning of the columns:

1) no_error means a correct reply with kss commands in it.

2) no_commands means correct reply but empty, contains no commands. 
Previously we gave a warning for this, now this is perfectly ok (as there 
are valid use cases for it), however it's a separate use case that needs 
a separate test.

3) server-exception means there was an exception on the server so no 
commands arrived. Instead a normal error page arrives and the log should 
actually write the server side exception as a reason "Client reason:" to 
the problem. (This is done by a trick: the server error page contains 
kukit commands with the exception info.)
A timeout  belongs to this case as well but that is difficult to test 
this way. First I had tests for timeout too but it was confusing for the 
users.

4) server-explicit-error: this happens if the server wants to raise an 
error to the client explicitely. The server needs to raise a 
KSSExplicitError for this. In this case a valid kukit response is 
generated that holds the error (in contrary to the server error template 
of the previous case). The client handles this in the same way as the 
previous case but gives 
"Server reason:" log of the message of the KSSExplicitError.



-- 
Balazs Ree



More information about the Kss-devel mailing list