Author: wyoung
Date: Tue Jun 26 04:06:00 2007
New Revision: 1609
URL: http://svn.gna.org/viewcvs/mysqlpp?rev=1609&view=rev
Log:
Reworked userman section on exceptions
Modified:
trunk/doc/userman/userman.dbx
Modified: trunk/doc/userman/userman.dbx
URL:
http://svn.gna.org/viewcvs/mysqlpp/trunk/doc/userman/userman.dbx?rev=1609&r1=1608&r2=1609&view=diff
==============================================================================
--- trunk/doc/userman/userman.dbx (original)
+++ trunk/doc/userman/userman.dbx Tue Jun 26 04:06:00 2007
@@ -421,30 +421,32 @@
errors. Most of the examples have a full set of exception
handlers. This is worthy of emulation.</para>
- <para>All of MySQL++'s custom exceptions derive from a common
- base class, <ulink type="classref" url="Exception"/>. That
- in turn derives from the Standard C++ exception base class,
- <classname>std::exception</classname>. Since the library
+ <para>All of MySQL++'s custom exceptions derive
+ from a common base class, <ulink type="classref"
+ url="Exception"/>. That in turn derives from Standard C++'s
+ <classname>std::exception</classname> class. Since the library
can indirectly cause exceptions to come from the Standard C++
Library, it's possible to catch all exceptions from MySQL++
- by just catching <classname>std::exception</classname>
- by reference. However, it's usually better to catch the
- all of the concrete exception types that you expect,
- and add a handler for <classname>Exception</classname> or
+ by just catching <classname>std::exception</classname> by
+ reference. However, it's better to have individual catch blocks
+ for each of the concrete exception types that you expect, and
+ add a handler for either <classname>Exception</classname> or
<classname>std::exception</classname> to act as a "catch-all"
for unexpected exceptions.</para>
- <para>Some of these exceptions are optional. When disabled,
- the object signals errors in some other way, typically by
- returning an error code or setting an error flag. Classes
- that support this feature derive from <ulink type="classref"
- url="OptionalExceptions"/>. Moreover, when such an object
- creates another object that also derives from this interface,
- it passes on its exception flag. Since everything flows
- from the <ulink type="classref" url="Connection"/> object,
- disabling exceptions on it at the start of the program disables
- all optional exceptions. You can see this technique at work in
- the "simple" examples, which keeps them, well, simple.</para>
+ <para>Some of these exceptions are optional. When exceptions
+ are disabled on a MySQL++ object, it signals errors in some
+ other way, typically by returning an error code or setting
+ an error flag. Classes that support this feature derive
+ from <ulink type="classref" url="OptionalExceptions"/>.
+ Moreover, when such an object creates another object
+ that also derives from this interface, it passes on its
+ exception flag. Since everything flows from the <ulink
+ type="classref" url="Connection"/> object, disabling
+ exceptions on it at the start of the program disables all
+ optional exceptions. You can see this technique at work in the
+ <filename>simple[1-3]</filename> examples, which keeps them,
+ well, simple.</para>
<para>Real-world code typically can't afford to lose out on the
additional information and control offered by exceptions. But
@@ -462,14 +464,19 @@
technique at work.</para>
<para>When one <classname>OptionalExceptions</classname>
- derivative creates another such object and passes on its
- exception flag, it passes a copy of the flag. Therefore,
- the two objects' flags operate independently after the new
- one is created. There's no way to globally enable or disable
- this flag on existing objects in a single call.</para>
-
- <para>There are some exceptions MySQL++ can throw that are
- not optional:</para>
+ derivative passes its exceptions flag to another such object,
+ it is only passing a copy. This means that the two objects'
+ flags operate independently. There's no way to globally
+ enable or disable this flag on existing objects in a single
+ call. If you're using the <classname>NoExceptions</classname>
+ feature and you're still seeing optional exceptions thrown, you
+ disabled exceptions on the wrong object. The exception thrower
+ could be unrelated to the object you disabled exceptions on,
+ it could be its parent, or it could be a child created before
+ you changed the exception throwing flag.</para>
+
+ <para>Some of the exceptions MySQL++ can throw are not
+ optional:</para>
<itemizedlist>
<listitem><para>The largest set of non-optional exceptions
_______________________________________________
Mysqlpp-commits mailing list
[email protected]
https://mail.gna.org/listinfo/mysqlpp-commits
