Re: SRFI-64: test exception symbol

[Vladimir Zhbanov]

Hi Taylan,

On Fri, May 01, 2020 at 11:58:41AM +0200, Taylan Kammer wrote:
> On 30.04.2020 17:55, Vladimir Zhbanov wrote:
> > On Thu, Apr 30, 2020 at 06:06:21PM +0300, Vladimir Zhbanov wrote:
> > > Hi,
> > > 
> > > In SRFI-64, is there a way to test what exception raised using
> > > test-error() or anything else?  I know about looking into test
> > > logs (if 'test-error' is used), though that's not what I need.  I
> > > need a way to be sure a test raises the exception it should raise.
> 
> The test-error form takes two optional operands before the test expression.
> It's defined as:
> 
> <start snip>
> 
> (test-error [[test-name] error-type] test-expr)
> 
> Evaluating test-expr is expected to signal an error. The kind of error is
> indicated by error-type.
> 
> If the error-type is left out, or it is #t, it means "some kind of
> unspecified error should be signaled". For example:
> 
> (test-error #t (vector-ref '#(1 2) 9))
> 
> This specification leaves it implementation-defined (or for a future
> specification) what form test-error may take, though all implementations
> must allow #t. Some implementations may support SRFI-35's conditions, but
> these are only standardized for SRFI-36's I/O conditions, which are seldom
> useful in test suites. An implementation may also allow
> implementation-specific "exception types". For example Java-based
> implementations may allow the names of Java exception classes:
> 
> ;; Kawa-specific example
> (test-error <java.lang.IndexOutOfBoundsException> (vector-ref '#(1 2) 9))
> 
> An implementation that cannot catch exceptions should skip test-error forms.
> 
> <end snip>

Well, I'm aware of this, thank you :-)

> My SRFI-64 implementation allows the error-type operand to be a predicate
> (one-argument procedure that returns a Boolean) to allow maximum
> flexibility.  It's found here:
> 
> https://github.com/TaylanUB/scheme-srfis

Thank you, I'd really like to try your implementation together
with my code. Though I don't know how :-(

The issue with this solution is how I would use the code and
integrate it into our project.

The first question: supposed that I already have guile installed
(together with its own srfi's) and have downloaded your
repository, how can I use your modules in my own code then?

The second one: how to make your code available for our code in
the spread of distributions our project builds on?  Probably,
there is a way to uniformly integrate some parts of it
(e.g. srfi-64) to our project?  Or should I require distribution
packagers working on packaging of our project to package your code
as a some new package, too?  Not sure, how to achieve this and if
this is possible at all.

Any hints?

-- 
  Vladimir

(λ)επτόν EDA — https://github.com/lepton-eda