Index: doc/proposals/exceptions-assert.md
===================================================================
--- doc/proposals/exceptions-assert.md	(revision 63917abc8d84f43ab52f2b99b5f7c3774273a32b)
+++ doc/proposals/exceptions-assert.md	(revision 58560d27705ae8b410c891acf6f69ae97480b871)
@@ -649,4 +649,28 @@
 enough for a user facing error message.
 
+### THE CHECKED EXCEPTION PROBLEM
+Yes, this gets an all caps title (it almost got its own section) because the
+single biggest concern about this system is the additional workload of
+maintaining checked exception lists on all functions. This is a real concern
+but I believe this proposal avoids the worst of it.
+
+One part of "the worst of it" is the annotating of many functions that call
+some distant helper function that throws an unhandled exception.
+At this point, it can be impossible to preform any sort of detailed recovery.
+In these cases the exceptions should be converted to cancellations.
+
+In my experiance the majority of exception throws (writen, not fired) are
+effectively assertion failures that are only catchable exceptions out of
+princible (or are in a long running program were individual operations can
+just be written off). Cancellation replaces all of these cases instead of
+the new exception system.
+
+Another part is the interaction with higher order functions.
+If a higher order function only works with particular exceptions thrown from
+the function passed to it, it loses a lot of its flexibility.
+Both polymorphism and exception tunnelling are ways to address this problem.
+These stratagies both mean you don't need many different variations of those
+functions, and hopefully have little (or no) additional code.
+
 ### Default Exception Handlers
 Handling every exception has often proven more work than people want to put