fixed a few more title and heading casings

mikeblome · mikeblome · commit e257238b6775 · 2019-11-19T10:39:37.000-08:00
diff --git a/docs/cpp/bad-cast-exception.md b/docs/cpp/bad-cast-exception.md
@@ -1,11 +1,11 @@
 ---
-title: "bad_cast Exception"
+title: "bad_cast exception"
 ms.date: "10/04/2019"
 f1_keywords: ["bad_cast", "bad_cast_cpp"]
 helpviewer_keywords: ["exceptions [C++], bad_cast", "bad_cast keyword [C++]"]
 ms.assetid: 31eae1e7-d8d5-40a0-9fef-64a6a4fc9021
 ---
-# bad_cast Exception
+# bad_cast exception
 
 The **bad_cast** exception is thrown by the **dynamic_cast** operator as the result of a failed cast to a reference type.
 
diff --git a/docs/cpp/bad-typeid-exception.md b/docs/cpp/bad-typeid-exception.md
@@ -1,11 +1,11 @@
 ---
-title: "bad_typeid Exception"
+title: "bad_typeid exception"
 ms.date: "10/04/2019"
 f1_keywords: ["bad_typeid", "bad_typeid_cpp"]
 helpviewer_keywords: ["bad_typeid exception", "exceptions [C++], bad_typeid"]
 ms.assetid: 5963ed58-4ede-4597-957d-f7bbd06299c2
 ---
-# bad_typeid Exception
+# bad_typeid exception
 
 The **bad_typeid** exception is thrown by the [typeid operator](../cpp/typeid-operator.md) when the operand for **typeid** is a NULL pointer.
 
diff --git a/docs/cpp/cleaning-up-resources.md b/docs/cpp/cleaning-up-resources.md
@@ -60,5 +60,5 @@ int main() {
 
 ## See also
 
-[Writing a Termination Handler](../cpp/writing-a-termination-handler.md)<br/>
+[Writing a termination handler](../cpp/writing-a-termination-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
diff --git a/docs/cpp/exception-specifications-throw-cpp.md b/docs/cpp/exception-specifications-throw-cpp.md
@@ -1,10 +1,10 @@
 ---
-title: "Exception Specifications (throw, noexcept) (C++)"
+title: "Exception specifications (throw, noexcept) (C++)"
 ms.date: "01/18/2018"
 helpviewer_keywords: ["exceptions [C++], exception specifications", "throwing exceptions [C++], throw keyword", "C++ exception handling [C++], throwing exceptions", "throw keyword [C++]", "noexcept keyword [C++]"]
 ms.assetid: 4d3276df-6f31-4c7f-8cab-b9d2d003a629
 ---
-# Exception Specifications (throw, noexcept) (C++)
+# Exception specifications (throw, noexcept) (C++)
 
 Exception specifications are a C++ language feature that indicate the programmer's intent about the exception types that can be propagated by a function. You can specify that a function may or may not exit by an exception by using an *exception specification*. The compiler can use this information to optimize calls to the function, and to terminate the program if an unexpected exception escapes the function.
 
diff --git a/docs/cpp/exceptions-and-stack-unwinding-in-cpp.md b/docs/cpp/exceptions-and-stack-unwinding-in-cpp.md
@@ -1,6 +1,6 @@
 ---
-title: "Exceptions and Stack Unwinding in C++"
-ms.date: "11/04/2016"
+title: "Exceptions and stack unwinding in C++"
+ms.date: "11/19/2019"
 ms.assetid: a1a57eae-5fc5-4c49-824f-3ce2eb8129ed
 ---
 # Exceptions and Stack Unwinding in C++
@@ -17,7 +17,7 @@ In the C++ exception mechanism, control moves from the throw statement to the fi
 
 1. If a matching **catch** handler is found, and it catches by value, its formal parameter is initialized by copying the exception object. If it catches by reference, the parameter is initialized to refer to the exception object. After the formal parameter is initialized, the process of unwinding the stack begins. This involves the destruction of all automatic objects that were fully constructed—but not yet destructed—between the beginning of the **try** block that is associated with the **catch** handler and the throw site of the exception. Destruction occurs in reverse order of construction. The **catch** handler is executed and the program resumes execution after the last handler—that is, at the first statement or construct that is not a **catch** handler. Control can only enter a **catch** handler through a thrown exception, never through a **goto** statement or a **case** label in a **switch** statement.
 
-## Stack Unwinding Example
+## Stack unwinding example
 
 The following example demonstrates how the stack is unwound when an exception is thrown. Execution on the thread jumps from the throw statement in `C` to the catch statement in `main`, and unwinds each function along the way. Notice the order in which the `Dummy` objects are created and then destroyed as they go out of scope. Also notice that no function completes except `main`, which contains the catch statement. Function `A` never returns from its call to `B()`, and `B` never returns from its call to `C()`. If you uncomment the definition of the `Dummy` pointer and the corresponding delete statement, and then run the program, notice that the pointer is never deleted. This shows what can happen when functions do not provide an exception guarantee. For more information, see How to: Design for Exceptions. If you comment out the catch statement, you can observe what happens when a program terminates because of an unhandled exception.
 
@@ -100,4 +100,4 @@ int main()
     Exiting main.
 
 */
-```
+```
diff --git a/docs/cpp/hardware-exceptions.md b/docs/cpp/hardware-exceptions.md
@@ -1,10 +1,10 @@
 ---
-title: "Hardware Exceptions"
+title: "Hardware exceptions"
 ms.date: "11/04/2016"
 helpviewer_keywords: ["exceptions [C++], hardware", "errors [C++], low-level", "errors [C++], hardware", "hardware exceptions [C++]", "low level errors"]
 ms.assetid: 06ac6f01-a8cf-4426-bb12-1688315ae1cd
 ---
-# Hardware Exceptions
+# Hardware exceptions
 
 Most of the standard exceptions recognized by the operating system are hardware-defined exceptions. Windows recognizes a few low-level software exceptions, but these are usually best handled by the operating system.
 
@@ -31,5 +31,5 @@ Many of the exceptions listed in the previous table are intended to be handled b
 
 ## See also
 
-[Writing an Exception Handler](../cpp/writing-an-exception-handler.md)<br/>
+[Writing an exception handler](../cpp/writing-an-exception-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
diff --git a/docs/cpp/mixing-c-structured-and-cpp-exceptions.md b/docs/cpp/mixing-c-structured-and-cpp-exceptions.md
@@ -1,10 +1,10 @@
 ---
-title: "Mixing C (Structured) and C++ exceptions"
+title: "Mixing C (structured) and C++ exceptions"
 ms.date: "08/14/2018"
 helpviewer_keywords: ["exceptions [C++], mixed C and C++", "C++ exception handling, mixed-language", "structured exception handling [C++], mixed C and C++", "catch keyword [C++], mixed", "try-catch keyword [C++], mixed-language"]
 ms.assetid: a149154e-36dd-4d1a-980b-efde2a563a56
 ---
-# Mixing C (Structured) and C++ exceptions
+# Mixing C (structured) and C++ exceptions
 
 If you want to write portable code, the use of structured exception handling (SEH) in a C++ program isn't recommended. However, you may sometimes want to compile using [/EHa](../build/reference/eh-exception-handling-model.md) and mix structured exceptions and C++ source code, and need some facility for handling both kinds of exceptions. Because a structured exception handler has no concept of objects or typed exceptions, it can't handle exceptions thrown by C++ code. However, C++ **catch** handlers can handle structured exceptions. C++ exception handling syntax (**try**, **throw**, **catch**) isn't accepted by the C compiler, but structured exception handling syntax (**__try**, **__except**, **__finally**) is supported by the C++ compiler.
 
diff --git a/docs/cpp/raising-software-exceptions.md b/docs/cpp/raising-software-exceptions.md
@@ -1,10 +1,10 @@
 ---
-title: "Raising Software Exceptions"
+title: "Raising software exceptions"
 ms.date: "11/04/2016"
 helpviewer_keywords: ["run-time errors, treating as exceptions", "exception handling [C++], errors as exceptions", "exceptions [C++], flagging errors as exceptions", "errors [C++], treating as exceptions", "exception handling [C++], detecting errors", "structured exception handling [C++], errors as exceptions", "exceptions [C++], software", "RaiseException function", "software exceptions [C++]", "formats [C++], exception codes"]
 ms.assetid: be1376c3-c46a-4f52-ad1d-c2362840746a
 ---
-# Raising Software Exceptions
+# Raising software exceptions
 
 Some of the most common sources of program errors are not flagged as exceptions by the system. For example, if you attempt to allocate a memory block but there is insufficient memory, the run-time or API function does not raise an exception but returns an error code.
 
@@ -57,5 +57,5 @@ __except (GetExceptionCode() == STATUS_INSUFFICIENT_MEM ||
 
 ## See also
 
-[Writing an Exception Handler](../cpp/writing-an-exception-handler.md)<br/>
-[Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
+[Writing an exception handler](../cpp/writing-an-exception-handler.md)<br/>
+[Structured exception handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
diff --git a/docs/cpp/restrictions-on-exception-handlers.md b/docs/cpp/restrictions-on-exception-handlers.md
@@ -1,10 +1,10 @@
 ---
-title: "Restrictions on Exception Handlers"
+title: "Restrictions on exception handlers"
 ms.date: "11/04/2016"
 helpviewer_keywords: ["restrictions, exception handlers", "exception handling [C++], exception handlers"]
 ms.assetid: 31d63524-0e8c-419f-b87c-061f4c0ea470
 ---
-# Restrictions on Exception Handlers
+# Restrictions on exception handlers
 
 The principal limitation to using exception handlers in code is that you cannot use a **goto** statement to jump into a **__try** statement block. Instead, you must enter the statement block through normal flow of control. You can jump out of a **__try** statement block and nest exception handlers as you choose.
 
diff --git a/docs/cpp/restrictions-on-termination-handlers.md b/docs/cpp/restrictions-on-termination-handlers.md
@@ -14,5 +14,5 @@ A **return** statement inside a **__finally** statement block presents roughly t
 
 ## See also
 
-[Writing a Termination Handler](../cpp/writing-a-termination-handler.md)<br/>
+[Writing a termination handler](../cpp/writing-a-termination-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
diff --git a/docs/cpp/structured-exception-handling-c-cpp.md b/docs/cpp/structured-exception-handling-c-cpp.md
@@ -46,9 +46,9 @@ As it unwinds the stack, the operating system calls any termination handlers tha
 
 ## Next steps
 
-- [Writing an Exception Handler](../cpp/writing-an-exception-handler.md)
+- [Writing an exception handler](../cpp/writing-an-exception-handler.md)
 
-- [Writing a Termination Handler](../cpp/writing-a-termination-handler.md)
+- [Writing a termination handler](../cpp/writing-a-termination-handler.md)
 
 - [Handle structured exceptions in C++](../cpp/exception-handling-differences.md)
 
diff --git a/docs/cpp/timing-of-exception-handling-a-summary.md b/docs/cpp/timing-of-exception-handling-a-summary.md
@@ -1,10 +1,10 @@
 ---
-title: "Timing of Exception Handling: A Summary"
+title: "Timing of exception handling: A summary"
 ms.date: "05/07/2019"
 helpviewer_keywords: ["sequence [C++]", "sequence, of handlers", "exception handling [C++], timing", "setjmpex.h", "termination handlers [C++], timing", "setjmp.h", "handlers [C++], order of exception", "structured exception handling [C++], timing"]
 ms.assetid: 5d1da546-73fd-4673-aa1a-7ac0f776c420
 ---
-# Timing of Exception Handling: A Summary
+# Timing of exception handling: A summary
 
 A termination handler is executed no matter how the **__try** statement block is terminated. Causes include jumping out of the **__try** block, a `longjmp` statement that transfers control out of the block, and unwinding the stack due to exception handling.
 
@@ -35,5 +35,5 @@ When the cause for interruption is an exception, the system must first execute t
 
 ## See also
 
-[Writing a Termination Handler](../cpp/writing-a-termination-handler.md)<br/>
+[Writing a termination handler](../cpp/writing-a-termination-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
diff --git a/docs/cpp/transporting-exceptions-between-threads.md b/docs/cpp/transporting-exceptions-between-threads.md
@@ -30,7 +30,7 @@ namespace std
 |*E*|A class that represents an exception.|
 |*e*|An instance of the parameter `E` class.|
 
-## Return Value
+## Return value
 
 The `current_exception` function returns an `exception_ptr` object that references the exception that is currently in progress. If no exception is in progress, the function returns an `exception_ptr` object that is not associated with any exception.
 
@@ -58,7 +58,7 @@ Most applications do not have to transport exceptions between threads. However,
 
 For more information about the C++ Standards committee proposal, search the Internet for document number N2179, titled "Language Support for Transporting Exceptions between Threads".
 
-### Exception-Handling Models and Compiler Options
+### Exception-handling models and compiler options
 
 Your application's exception-handling model determines whether it can catch and transport an exception. Visual C++ supports three models that can handle C++ exceptions, structured exception handling (SEH) exceptions, and common language runtime (CLR) exceptions. Use the [/EH](../build/reference/eh-exception-handling-model.md) and [/clr](../build/reference/clr-common-language-runtime-compilation.md) compiler options to specify your application's exception-handling model.
 
@@ -77,7 +77,7 @@ Only the following combination of compiler options and programming statements ca
 
 The following sections describe how to transport exceptions by using the `exception_ptr` type, and the `current_exception`, `rethrow_exception`, and `make_exception_ptr` functions.
 
-## exception_ptr Type
+## exception_ptr type
 
 Use an `exception_ptr` object to reference the current exception or an instance of a user-specified exception. In the Microsoft implementation, an exception is represented by an [EXCEPTION_RECORD](/windows/win32/api/winnt/ns-winnt-exception_record) structure. Each `exception_ptr` object includes an exception reference field that points to a copy of the `EXCEPTION_RECORD` structure that represents the exception.
 
@@ -91,7 +91,7 @@ Despite its name, an `exception_ptr` object is not itself a pointer. It does not
 
 You can use the equal (`==`) and not-equal (`!=`) operators to compare two `exception_ptr` objects. The operators do not compare the binary value (bit pattern) of the `EXCEPTION_RECORD` structures that represent the exceptions. Instead, the operators compare the addresses in the exception reference field of the `exception_ptr` objects. Consequently, a null `exception_ptr` and the NULL value compare as equal.
 
-## current_exception Function
+## current_exception function
 
 Call the `current_exception` function in a **catch** block. If an exception is in flight and the **catch** block can catch the exception, the `current_exception` function returns an `exception_ptr` object that references the exception. Otherwise, the function returns a null `exception_ptr` object.
 
@@ -103,7 +103,7 @@ The destructor for the current exception is called at the end of the **catch** b
 
 Successive calls to the `current_exception` function return `exception_ptr` objects that refer to different copies of the current exception. Consequently, the objects compare as unequal because they refer to different copies, even though the copies have the same binary value.
 
-### SEH Exceptions
+### SEH exceptions
 
 If you use the **/EHa** compiler option, you can catch an SEH exception in a C++ **catch** block. The `current_exception` function returns an `exception_ptr` object that references the SEH exception. And the `rethrow_exception` function throws the SEH exception if you call it with thetransported `exception_ptr` object as its argument.
 
@@ -115,13 +115,13 @@ If you catch an SEH exception, you must manage the memory referenced by any poin
 
 You can use structured exception (SE) translator functions together with the transport exceptions feature. If an SEH exception is translated to a C++ exception, the `current_exception` function returns an `exception_ptr` that references the translated exception instead of the original SEH exception. The `rethrow_exception` function subsequently throws the translated exception, not the original exception. For more information about SE translator functions, see [_set_se_translator](../c-runtime-library/reference/set-se-translator.md).
 
-## rethrow_exception Function
+## rethrow_exception function
 
 After you store a caught exception in an `exception_ptr` object, the primary thread can process the object. In your primary thread, call the `rethrow_exception` function together with the `exception_ptr` object as its argument. The `rethrow_exception` function extracts the exception from the `exception_ptr` object and then throws the exception in the context of the primary thread. If the *p* parameter of the `rethrow_exception` function is a null `exception_ptr`, the function throws [std::bad_exception](../standard-library/bad-exception-class.md).
 
 The extracted exception is now the current exception in the primary thread, and you can handle it as you would any other exception. If you catch the exception, you can handle it immediately or use a **throw** statement to send it to a higher level exception handler. Otherwise, do nothing and let the default system exception handler terminate your process.
 
-## make_exception_ptr Function
+## make_exception_ptr function
 
 The `make_exception_ptr` function takes an instance of a class as its argument and then returns an `exception_ptr` that references the instance. Usually, you specify an [exception class](../standard-library/exception-class.md) object as the argument to the `make_exception_ptr` function, although any class object can be the argument.
 
diff --git a/docs/cpp/try-except-statement.md b/docs/cpp/try-except-statement.md
@@ -158,6 +158,6 @@ world
 
 ## See also
 
-[Writing an Exception Handler](../cpp/writing-an-exception-handler.md)<br/>
+[Writing an exception handler](../cpp/writing-an-exception-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)<br/>
 [Keywords](../cpp/keywords-cpp.md)
diff --git a/docs/cpp/try-finally-statement.md b/docs/cpp/try-finally-statement.md
@@ -72,7 +72,7 @@ The termination handler is not called if a process is killed in the middle of ex
 
 ## See also
 
-[Writing a Termination Handler](../cpp/writing-a-termination-handler.md)<br/>
+[Writing a termination handler](../cpp/writing-a-termination-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)<br/>
 [Keywords](../cpp/keywords-cpp.md)<br/>
 [Termination-Handler Syntax](/windows/win32/Debug/termination-handler-syntax)
diff --git a/docs/cpp/unhandled-cpp-exceptions.md b/docs/cpp/unhandled-cpp-exceptions.md
@@ -1,10 +1,10 @@
 ---
-title: "Unhandled C++ Exceptions"
+title: "Unhandled C++ exceptions"
 ms.date: "11/04/2016"
 helpviewer_keywords: ["event handlers [C++], unhandled exceptions", "catch keyword [C++], handler not found", "exceptions [C++], unhandled", "C++ exception handling, unhandled exceptions", "unhandled exceptions [C++]"]
 ms.assetid: 13f09c53-9254-4407-9db9-14e730e047cc
 ---
-# Unhandled C++ Exceptions
+# Unhandled C++ exceptions
 
 If a matching handler (or ellipsis **catch** handler) cannot be found for the current exception, the predefined `terminate` run-time function is called. (You can also explicitly call `terminate` in any of your handlers.) The default action of `terminate` is to call `abort`. If you want `terminate` to call some other function in your program before exiting the application, call the `set_terminate` function with the name of the function to be called as its single argument. You can call `set_terminate` at any point in your program. The `terminate` routine always calls the last function given as an argument to `set_terminate`.
 
diff --git a/docs/cpp/writing-an-exception-filter.md b/docs/cpp/writing-an-exception-filter.md
@@ -1,10 +1,10 @@
 ---
-title: "Writing an Exception Filter"
+title: "Writing an exception filter"
 ms.date: "11/04/2016"
 helpviewer_keywords: ["exception handling [C++], filters"]
 ms.assetid: 47fc832b-a707-4422-b60a-aaefe14189e5
 ---
-# Writing an Exception Filter
+# Writing an exception filter
 
 You can handle an exception either by jumping to the level of the exception handler or by continuing execution. Instead of using the exception handler code to handle the exception and falling through, you can use *filter* to clean up the problem and then, by returning -1, resume normal flow without clearing the stack.
 
@@ -72,5 +72,5 @@ __except( nCode = GetExceptionCode(), nCode == STATUS_INTEGER_OVERFLOW )
 
 ## See also
 
-[Writing an Exception Handler](../cpp/writing-an-exception-handler.md)<br/>
+[Writing an exception handler](../cpp/writing-an-exception-handler.md)<br/>
 [Structured Exception Handling (C/C++)](../cpp/structured-exception-handling-c-cpp.md)
