Exception handling - symbol for encoding exception type?

Exception handling - symbol for encoding exception type?

[Zelphir Kaltstahl]

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

Re: Exception handling - symbol for encoding exception type?

[Vivien Kraus]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

Hello Zelphir,

Le mardi 08 mars 2022 à 17:11 +0000, Zelphir Kaltstahl a écrit :
> 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’m a big fan of the new exceptions, but I had the same question at
first. I tried some code that put everything into the message, I tried
some more code where every possible exception had its type and
contained its parameters, and at the end I settled on this rule of
thumb: if you’re doing something in your code and an exception might be
raised, catch it and raise it again with an additional message
(internationalize it please). If your program needs to perform more
tasks, such as banning the user that raised the exception, create a new
exception type with as few parameters as necessary (most of mine have
none), and raise an occurence of it as well as the internationalized
message. You can use make-exception to create an exception composed of
a new message and an existing exception, and no information will be
lost.

More generally, don’t bother with a new exception type until you need
it to do something useful.

Of course, this is my opinion, others may view the problem differently.

Vivien

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 695 bytes --]

Re: Exception handling - symbol for encoding exception type?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

Zelphir Kaltstahl schreef op di 08-03-2022 om 17:11 [+0000]:
> 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?

There's plenty of problems that don't fit with the pre-existing
exception types well, so I don't see a problem with defining new
exception types.

E.g., in Guix, to indicate that a file 'bin/foo' could not be found, we
throw a '&search-error':

  ;; this syntax might be wrong but you get the idea.
  (raise
    (condition
      (make-search-error "bin/foo")
      (make-fix-hint "add the package foobar to the inputs of baz)
      (make-location "at this file, that line, that column")))

(actually there are less components due to $REASONS that aren't
relevant here)

guix/ui then translates this condition to nice error+hint messages
(actually it doesn't due to $REASONS that are again not relevant here):

  FILE:LINE:COLUMN: error: the file bin/foo could not be found
  hint: Add the package 'foobar' to the inputs of 'baz'

I recommend defining new exceptions types instead of fitting everything
into &message, that makes catching exceptions easier.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Exception handling - symbol for encoding exception type?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Zelphir Kaltstahl schreef op di 08-03-2022 om 17:11 [+0000]:
>        (make-non-continuable-error)

IIRC, 'make-non-continuable-error' indicates that someone tried to
continue into a raise-exception that wasn't continuable.  It does not
make things non-continuable, it just states that someone tried to
continue anyway.

What you seem to need is (raise-exception ... #:continuable? #false).
However, #:continuable? #false is the default.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Exception handling - symbol for encoding exception type?

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

Zelphir Kaltstahl schreef op di 08-03-2022 om 17:11 [+0000]:
> and that one should not try to create additional types? Or
> is the idea to encode more specifics into the &message?

Nothing is stopping you from including both a descriptive error
&message and an easily catchable and machine-readable &some-domain-
specific-exception.

Greetings,
Maxime

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Exception handling - symbol for encoding exception type?

[Olivier Dion via General Guile related discussions]

On Tue, 08 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:


> 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.

I would almost always make a type if the exception can be handled by
user code.  For internal raise/catch, not necessary.  This is also
better for testing purpose with srfi-64 `test-error` where you can
specify the error type.

-- 
Olivier Dion
Polymtl

Re: Exception handling - symbol for encoding exception type?

[Zelphir Kaltstahl]

Hi Maxime!

On 3/8/22 19:20, Maxime Devos wrote:
> Zelphir Kaltstahl schreef op di 08-03-2022 om 17:11 [+0000]:
>>         (make-non-continuable-error)
> IIRC, 'make-non-continuable-error' indicates that someone tried to
> continue into a raise-exception that wasn't continuable.  It does not
> make things non-continuable, it just states that someone tried to
> continue anyway.
>
> What you seem to need is (raise-exception ... #:continuable? #false).
> However, #:continuable? #false is the default.
>
> Greetings,
> Maxime.

I am late, but I finally get around to it: Thanks for this hint and explanation.

Best regards,
Zelphir

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