unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: guile-user <guile-user@gnu.org>
Subject: Exception handling - symbol for encoding exception type?
Date: Tue,  8 Mar 2022 17:11:26 +0000	[thread overview]
Message-ID: <18366d41-ee52-9122-997e-cd18b04ece3f@posteo.de> (raw)

Hello Guile users!

I have a question about exception handling.

Lets say I have some code raising some exception:

~~~~
(import (ice-9 exceptions))


(define something-causing-an-exception
   (λ ()
     (raise-exception
      (make-exception
       (make-non-continuable-error)
       (make-exception-with-message "Some error message.")
       (make-exception-with-irritants (list whatever is responsible for causing an error))
       (make-exception-with-origin 'name-of-procedure)))))


(with-exception-handler
     (λ (exception)
       ;; handling the exception
       ...)
   (λ ()
     (something-causing-an-exception))
   #:unwind? #t)
~~~~

On
https://www.gnu.org/software/guile/manual/html_node/Exception-Objects.html
I can see a hierarchy of exception types:

~~~~
&exception
|- &warning
|- &message
|- &irritants
|- &origin
\- &error
    |- &external-error
    \- &programming-error
       |- &assertion-failure
       |- &non-continuable
       |- &implementation-restriction
       |- &lexical
       |- &syntax
       \- &undefined-variable
~~~~

Is the idea, that one should rely merely on the existing
exception types, which are:

+ assertion-failure
+ non-continuable
+ implementation-restriction
+ lexical
+ syntax
+ undefined-variable

and that one should not try to create additional types? Or
is the idea to encode more specifics into the &message?

I guess I am looking for a way to specify a symbol and
later, when an exception happens, check for a symbol, to
know what the reason for the exception is, instead of
searching around in a &message string, which feels a bit
messy.

I think in some other languages this would be encoded in
the type or class or the exception itself. One would catch
only exceptions of a specific type. This is a convention
inside the code, which does not necessarily spread to other
programs or code bases.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl




             reply	other threads:[~2022-03-08 17:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 17:11 Zelphir Kaltstahl [this message]
2022-03-08 17:48 ` Exception handling - symbol for encoding exception type? Vivien Kraus
2022-03-08 18:18 ` Maxime Devos
2022-03-08 18:20 ` Maxime Devos
2022-04-07 21:39   ` Zelphir Kaltstahl
2022-03-08 18:22 ` Maxime Devos
2022-03-08 19:07 ` Olivier Dion via General Guile related discussions

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=18366d41-ee52-9122-997e-cd18b04ece3f@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --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).