unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Vladimir Zhbanov <vzhbanov@gmail.com>
To: guile-user@gnu.org
Subject: Re: SRFI-64: test exception symbol
Date: Fri, 1 May 2020 22:20:58 +0300	[thread overview]
Message-ID: <20200501192058.GA16326@newvzh.lokolhoz> (raw)
In-Reply-To: <920a5e8d-f1fd-6efa-b57a-9957f76784c6@gmail.com>

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



  reply	other threads:[~2020-05-01 19:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 15:06 SRFI-64: test exception symbol Vladimir Zhbanov
2020-04-30 15:55 ` Vladimir Zhbanov
2020-05-01  9:58   ` Taylan Kammer
2020-05-01 19:20     ` Vladimir Zhbanov [this message]
2020-05-02 19:38       ` Taylan Kammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200501192058.GA16326@newvzh.lokolhoz \
    --to=vzhbanov@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).