-
Notifications
You must be signed in to change notification settings - Fork 16
/
exception_safety.txt
53 lines (45 loc) · 4.38 KB
/
exception_safety.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
EXCEPTION SAFETY
NEW ET INT ==> #Tout new doit avoir, à la fin du bloc { } courant, un delete correspondant (et un seul).
#Toute CLASSDT pointeur doit avoir un delete dans ~CLASS
#On ne peut pas delete un ADR non initialisé, mais on peut delete un ADR initialisé à NULL.
#Sinon fuite de mémoire.
COPIE DE POINTEURS ==> #Attention, une ADR copie d'une autre ne peut plus être utilisée si la copie est deleted (et
#inversement)
#Solution -> shared_ptr
FONCTION RENVOYANT ADR
==> #Elle donne à la charge de l'user le soin de delete, ce qu'il vaut mieux éviter.
EXCEPTION-SAFE ==> #Cependant, les pointeurs ne sont pas exception-safe : en cas d'exception entre new et delete, il y a
#une fuite de mémoire.
#Il faut donc utiliser un RAII
#Les standards containers, dont STREAM et STRING sont tous exception-safe.
EXCEPTION-SAFETY ==> #Fait que, dans un bout de code, s'il y a une exception, le global state avant la section et après
#l'exception soient le même (i.e. invariants restent intacts ; i.e. pas de side effects)
#Concerne notamment l'allocation/désallocation de mémoire : une exception doit désallouer la mémoire
#allouée précédemment.
#Les différents degrés d'exception safety (exception guarentees, aka Abrahams guarentees) sont, du
#moins bien ou mieux :
# - basic guarentee : si exception, invariantes demeurent les mêmes, et pas de memory leak (RAII)
# - strong guarentee : si exception, opérations précédentes sont inversées (Scoped Guards,
# boost::SCOPED_EXIT).
# En d'autres termes, la section a un state, et ce state après l'exception == celui avant début de
# la section.
# basic guarentee au contraire ou bien est une section stateless (auquel cas pas de distinction
# avec strong guarentee), ou laisse sur un state valide/safe, mais pas forcément celui du début.
# - no-throw guarentee : pas d'exception, à ne faire que si on est sûr qu'on a pas besoin de lancer
# d'exception et qu'on appelle aucune fonction pouvant le faire -> ne jamais inhiber une exception
#Tous les standards containers sont exception-safe.
EXCEPTION-NEUTRALITY ==>#Fait qu'une fonction recevant une exception d'un callee, s'il ne réussit pas à le traiter lui-même,
#la renvoie tel quelle à son propre caller.
LSP ET EXCEPTION-SAFETY #Une classe doit définir (design by contract) :
==> # - son exception-safety
# - les exceptions lancées
#Une méthode héritée d'un parent ne doit pas avoir une exception-safety moindre, ni lancer de nouvelles
#exceptions (mais peut l'inverse).
#Par conséquent, définir une exception-safety aussi forte que possible fait que les enfants seront
#plus contraints : penser donc à la baisser et à pouvoir des exceptions which might be thrown si on
#pense qu'enfants en auront peut être besoin.
DESTRUCTORS ==> #Ils doivent être nothrow : sinon les RAII ne peuvent pas marcher.
CONSTRUCTORS ==> #Ils peuvent tout à fait lancer des exceptions, et ce n'est pas une mauvaise chose.
#Il faut donc utiliser des RAII dans les constructors et non des new "nus" en cas d'exception lancée.