[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception handling - symbol for encoding exception type?

From: Vivien Kraus
Subject: Re: Exception handling - symbol for encoding exception type?
Date: Tue, 08 Mar 2022 18:48:52 +0100
User-agent: Evolution 3.42.1

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]