Re: Fixture.error() as well as exception()?

----- Original Message ----- 
From: "Rick Mugridge" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Tuesday, September 23, 2003 6:19 AM
Subject: [Fit-dev] Fixture.error() as well as exception()?


> I have code in several specialised fixture that has to throw an 
> exception (and thus call Fixture.exception()) because an argument is 
> invalid or whatever. The exception stackdump is irrelevant and clutters 
> up the result when all I want is to provide a simple error message. Eg, 
> "Unknown state".
> 
> Has anyone else struck this?

There are a number of examples in the sample programs
where a simple error message would be preferable to a
stack dump. I've never been comfortable with providing 
a stack dump where the error is something that could
reasonably be expected. I'd prefer to reserve stack dumps
for something that the developer has to fix,
rather than things like invalid input data that the test
writer has to fix.

> So I suggest adding a new 'colouring' method to Fixture, such as 
> error(). It takes a cell and a String and acts like wrong(), except that 
> the top half is just whatever was in the cell before and the bottom half 
> is just the error message.
> 
> That is, something like
> 
>     public void error(Parse cell, String message) {
>         wrong(cell);
>         cell.addToBody("<hr>" + escape(message));
>     }

It needs to be a different color than a simple wrong() though.
Otherwise, you've got the possibility of confusion with string
output.

The other question I have is: how does Fixture know that
the exception should be an error message rather than a
stack dump? I could undoubtedly manage this in the Python
version with a special exception class. Presumably the
Java version would be the same?

A related question is: how do you test error handling?
Right now, I believe "error" is a special word, but it does
not have the capability of checking for a specific error.
I think the only way to do it right now is to use a second
column (with it's own method, of course) to return the
error message. This needs to be clarified, I think, into a
standard (or at least recommended and supported) way 
of doing it.

John Roth

> 
> 
> Cheers, Rick
> 
> 
> _______________________________________________
> Fit-dev mailing list
> [email protected]
> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev