问题来源：
UDT的android平台移植过程中，在用NDK编译buffer.cpp文件时出现error: exception handling disabled, use -fexceptions to enable。
问题解决：
此问题的出现是编译器的异常异常捕获被禁用了，需要在Android.mk文件中开启。在Android.mk文件中添加： LOCAL_CPPFLAGS += -fexceptions就可以了。或者在Application.mk文件中添加APP_CPPFLAGS += -fexceptions
也是可以的。
补充：
Android NDK r5对C++的支持情况
android平台提供了一个最小化的C++运行库(/system/lib/libstdc++)以及与之对应的头文件。
1、C++的异常支持：
从NDK r5就开始NDK的工具链就开始支持了C++的异常控制，只不过为了通用性的原因，所有的C++原文件被编译的时候都是默认的是-fno-exceptions，即不不支持异常控制的。
使用-fexceptions标记可以开启异常控制。所以你只需要在你的每个模块的Android.mk中添加LOCAL_CPPFLAGS += -fexceptions就可以了。
更简单的是，在你的Application.mk文件中添加APP_CPPFLAGS += -fexceptions，这种配置会自动应用到你工程的所有模块当中。
注意:
已被废弃的"arm-eabi-4.4.0"工具链提供的向后兼容的NDK是不支持异常的。
2、RTTI support:
从NDK r5开始，NDK工具链也开始支持C++ RTTI（Runtime Type Information）了。但是，为了通用性的，所有的C++源文件被构建的时候默认是不支持RRRI的（-fno-rtti）。需要开启的话，你需要在Android.mk中添加：LOCAL_CPPFLAGS += -frtti，或者更简单的做法是在Application.mk添加APP_CPPFLAGS += -frtti。
注意:
已被废弃的"arm-eabi-4.4.0"工具链提供的向后兼容的NDK是不支持RTTI的。
III. Selecting the C++ Standard Library Implementation:
By default, the headers and libraries for the minimal C++ runtime system
library (/system/lib/libstdc++.so) are used when building C++ sources.
You can however select a different implementation by setting the variable
APP_STL to something else in your Application.mk, for example:
APP_STL := stlport_static
To select the static STLport implementation provided with this NDK.
Value APP_STL values are the following:
system -> Use the default minimal C++ runtime library.
stlport_static -> Use STLport built as a static library.
stlport_shared -> Use STLport built as a shared library.
WARNING: IMPORTANT CAVEAT
AT THE MOMENT, OUR STLPORT IMPLEMENTATION DOES NOT SUPPORT EXCEPTIONS
AND RTTI. PLEASE BE SURE TO NOT USE -fexceptions OR -frtti IN ALL
MODULES THAT USE IT.
WARNING: END OF IMPORTANT CAVEAT
"stlport_shared" is preferred if you have several shared libraries in your
project that use the C++ STL, because it avoids duplication of functions
and more importantly of global variables (e.g. std::cout) in each one of
them, which can have surprising results.
On the other hand, you will have to load it explicitely when starting your
application, as in the following example:
static {
System.loadLibrary("stlport_shared");
System.loadLibrary("foo");
System.loadLibrary("bar");
}
Where both "libfoo.so" and "libbar.so" depend on "libstlport_shared.so".
Note that the shared library's name if "libstlport_shared.so" to avoid
naming conflicts with certain Android system images which include a
system-level libstlport.so (which happens to not be ABI-stable and
cannot be used from NDK-generated machine code).
"stlport_static" is preferred if you have only one shared library in your
project: only the STL functions and variables you actually need will be
linked to your machine code, reducing its code size, and you won't need
to load the dynamic stlport_shared at startup.
IV. STLport-specific issues:
----------------------------
This NDK provides prebuilt static and shared libraries for STLport,
but you can force it to be rebuilt from sources by defining the following
in your environment or your Application.mk before building:
STLPORT_FORCE_REBUILD := true
STLport is licensed under a BSD-style open-source license. See
sources/cxx-stl/stlport/README for more details about the library.
V. Future Plans:
----------------
- Make STLport compatible with C++ exceptions and RTTI
- Full GNU libstdc++ support