On Sat, Jun 11, 2022 at 05:29:38PM +0000, Waldek Hebisch wrote:
> On Sat, Jun 11, 2022 at 04:30:42PM +0200, Ralf Hemmecke wrote:
> > Hmmm, it seems that the unittest.spad is not really something that works
> > nicely if there are testLibraryError calls to be tested.
> >
> > I just figured out that if I have foo.input (see attachment), then the
> > output will be (see below), i.e. the B tests are never executed.
>
> Yes. AFAICS the unittest code really does not catch error, instead
> depends on toplevel intepreter loop to restart test script at next
> toplevel construct. Probaby similar problem appears when there are
> fatal tests. We probably should implement this part of unittest
> differently, to catch errors. More preciesly, we need function
> 'catch_all_errors' (or maybe 'ignore_errors') that executes code
> (function) catching all errors.
We actually have special macro 'trappedSpadEval' to catch errors
during evaluation. It missed few errors, so I had to modify our
error handling. Now it looks that it catches all errors.
I also modified 'unittest.spad' to use 'trappedSpadEval'.
AFAICS now errors do not propagate past test constructs.
In particular 'testLibraryError' returns to relevant block.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20220718135648.GA30364%40fricas.math.uni.wroc.pl.
