Re: Exception handling - symbol for encoding exception type?

[Vivien Kraus]

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

signature.asc
Description: This is a digitally signed message part