From 56a941a7f86dcfb6bbba020c73c4cef75ca611e0 Mon Sep 17 00:00:00 2001
From: shaneasd <thatguyiknow5@hotmail.com>
Date: Fri, 11 Oct 2019 02:30:51 +0800
Subject: [PATCH] Fix discussion link in C.36 (#1523)

---
 CppCoreGuidelines.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md
index 25e8a3d..3b9ad63 100644
--- a/CppCoreGuidelines.md
+++ b/CppCoreGuidelines.md
@@ -4998,7 +4998,7 @@ Many have tried to devise a fool-proof scheme for dealing with failure in destru
 None have succeeded to come up with a general scheme.
 This can be a real practical problem: For example, what about a socket that won't close?
 The writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception.
-See [discussion](#Sd-dtor).
+See [discussion](#Sd-never-fail).
 To make the problem worse, many "close/release" operations are not retryable.
 If at all possible, consider failure to close/cleanup a fundamental design error and terminate.