Anchor links

Colin Robertson · Colin Robertson · commit 7dd30c3f0214 · 2020-08-25T03:56:15.000-07:00
diff --git a/docs/cpp/errors-and-exception-handling-modern-cpp.md b/docs/cpp/errors-and-exception-handling-modern-cpp.md
@@ -62,15 +62,15 @@ Exceptions in C++ resemble ones in languages such as C# and Java. In the **`try`
 
 Robust error handling is challenging in any programming language. Although exceptions provide several features that support good error handling, they can't do all the work for you. To realize the benefits of the exception mechanism, keep exceptions in mind as you design your code.
 
-- Use asserts to check for errors that should never occur. Use exceptions to check for errors that might occur, for example, errors in input validation on parameters of public functions. For more information, see the [Exceptions versus assertions](#exceptions-versus-assertions) section.
+- Use asserts to check for errors that should never occur. Use exceptions to check for errors that might occur, for example, errors in input validation on parameters of public functions. For more information, see the [Exceptions versus assertions](#exceptions_versus_assertions) section.
 
 - Use exceptions when the code that handles the error is separated from the code that detects the error by one or more intervening function calls. Consider whether to use error codes instead in performance-critical loops, when code that handles the error is tightly coupled to the code that detects it.
 
 - For every function that might throw or propagate an exception, provide one of the three exception guarantees: the strong guarantee, the basic guarantee, or the nothrow (noexcept) guarantee. For more information, see [How to: Design for exception safety](how-to-design-for-exception-safety.md).
 
 - Throw exceptions by value, catch them by reference. Don’t catch what you can't handle.
 
-- Don't use exception specifications, which are deprecated in C++11. For more information, see the [Exception specifications and `noexcept`](#exception-specifications-and-noexcept) section.
+- Don't use exception specifications, which are deprecated in C++11. For more information, see the [Exception specifications and `noexcept`](#exception_specifications_and_noexcept) section.
 
 - Use standard library exception types when they apply. Derive custom exception types from the [`exception` Class](../standard-library/exception-class.md) hierarchy.
 
@@ -80,7 +80,7 @@ Robust error handling is challenging in any programming language. Although excep
 
 The exception mechanism has a minimal performance cost if no exception is thrown. If an exception is thrown, the cost of the stack traversal and unwinding is roughly comparable to the cost of a function call. Additional data structures are required to track the call stack after a **`try`** block is entered, and additional instructions are required to unwind the stack if an exception is thrown. However, in most scenarios, the cost in performance and memory footprint isn't significant. The adverse effect of exceptions on performance is likely to be significant only on memory-constrained systems. Or, in performance-critical loops, where an error is likely to occur regularly and there's tight coupling between the code to handle it and the code that reports it. In any case, it's impossible to know the actual cost of exceptions without profiling and measuring. Even in those rare cases when the cost is significant, you can weigh it against the increased correctness, easier maintainability, and other advantages that are provided by a well-designed exception policy.
 
-## <a href="exceptions-versus-assertions"></a> Exceptions versus assertions
+## <a href="exceptions_versus_assertions"></a> Exceptions versus assertions
 
 Exceptions and asserts are two distinct mechanisms for detecting run-time errors in a program. Use `assert` statements to test for conditions during development that should never be true if all your code is correct. There's no point in handling such an error by using an exception, because the error indicates that something in the code has to be fixed. It doesn't represent a condition that the program has to recover from at run time. An `assert` stops execution at the statement so that you can inspect the program state in the debugger. An exception continues execution from the first appropriate catch handler. Use exceptions to check error conditions that might occur at run time even if your code is correct, for example, "file not found" or "out of memory." Exceptions can handle these conditions, even if the recovery just outputs a message to a log and ends the program. Always check arguments to public functions by using exceptions. Even if your function is error-free, you might not have complete control over arguments that a user might pass to it.
 
@@ -90,7 +90,7 @@ Both C and C++ programs can use the structured exception handling (SEH) mechanis
 
 For more information about SEH, see [Structured Exception Handling (C/C++)](structured-exception-handling-c-cpp.md).
 
-## <a href="exception-specifications-and-noexcept"></a> Exception specifications and `noexcept`
+## <a href="exception_specifications_and_noexcept"></a> Exception specifications and `noexcept`
 
 Exception specifications were introduced in C++ as a way to specify the exceptions that a function might throw. However, exception specifications proved problematic in practice, and are deprecated in the C++11 draft standard. We recommend that you don't use **`throw`** exception specifications except for `throw()`, which indicates that the function allows no exceptions to escape. If you must use exception specifications of the deprecated form `throw( type-name )`, MSVC support is limited. For more information, see [Exception Specifications (throw)](exception-specifications-throw-cpp.md). The **`noexcept`** specifier is introduced in C++11 as the preferred alternative to `throw()`.
 
diff --git a/docs/error-messages/compiler-errors-2/compiler-error-c2703.md b/docs/error-messages/compiler-errors-2/compiler-error-c2703.md
@@ -32,6 +32,6 @@ int main() {
 
 ## See also
 
-[The `__leave` keyword](/cpp/cpp/try-except-statement#__leave)\
-[`try-except` statement](/cpp/cpp/try-except-statement)\
-[`try-finally` statement](/cpp/cpp/try-finally-statement)
+[The `__leave` keyword](../../cpp/try-except-statement.md#__leave)\
+[`try-except` statement](../../cpp/try-except-statement.md)\
+[`try-finally` statement](../../cpp/try-finally-statement.md)
