java获取异常堆栈信息

‘壹’ java中try...catch捕获异常是如何判断当前这个异常时属于什么异常的

java中所有的异常都会继承Exception这个父类.Java程序在执行过程中如果出现异常，会自动生成一个异常类对象，该异常对象将被自动提交给JVM，这个过程称为抛出(throw)异常。getMessage() 方法，用来获得有关异常事件的字符串信息。printStackTrace() 方法，用来跟踪异常事件发生时执行堆栈的内容。你可以用e.getMessage()获取异常信息.

‘贰’ slf4j怎么打印java错误堆栈信息throwable对象

SLF4J 1.6.0以前的版本，如果打印异常堆栈信息，必须用

log.error(Stringmsg,Throwablet)

log.info等对应方法．

如果msg含有变量，一般用String.format方法格式化msg.

如果用

error(Stringformat,Object...arguments)

等其它方法，异常堆栈信息会丢失．

幸好，SLF4J 1.6.0以后的版本对这个不友好的异常信息log改进了．

error(Stringformat,Object…arguments)这个方法也会打印异常堆栈信息，只不过规定throwable对象必须为

最后一个参数．如果不遵守这个规定，异常堆栈信息不会log出来．

‘叁’ 怎么让程序异常退出时打印堆栈信息

打印堆栈是调试的常用方法，一般在系统异常时，我们可以将异常情况下的堆栈打印出来，这样十分方便错误查找。实际上还有另外一个非常有用的功能：分析代码的行为。android代码太过庞大复杂了，完全的静态分析经常是无从下手，因此通过打印堆栈的动态分析也十分必要。

Android打印堆栈的方法，简单归类一下
1. zygote的堆栈mp
实际上这个可以同时mp java线程及native线程的堆栈，对于java线程，java堆栈和native堆栈都可以得到。
使用方法很简单，直接在adb shell或串口中输入：
[plain] view plain
kill -3 <pid>
输出的trace会保存在 /data/anr/traces.txt文件中。这个需要注意，如果没有 /data/anr/这个目录或/data/anr/traces.txt这个文件，需要手工创建一下，并设置好读写权限。
如果需要在代码中，更容易控制堆栈的输出时机，可以用以下命令获取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一样的。
不过需要注意两点：
adb shell可能会没有权限，需要root。
android 4.2中关闭了native thread的堆栈打印，详见 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆栈的打印被关掉了！不过对于大多数情况，可以直接将这个注释打开。

‘肆’ Java语言中关于异常的问题

异常就是程序的非正常状态

遇到异常的话通常有两种解决方式
1
操作系统检查并终止程序的执行
2
由程序员在程序中引入入场处理的代码

JAVA语言引入了异常处理机制

可以预防错误的程序代码或者系统错误所造成的不良结果
并且当不可预期的错误发生时，异常处理机制会试图恢复异常发生前的状态或者妥善处理异常造成的问题。

JAVA异常处理机制是个很复杂的问题，这只是最基础的。

getMessage
public String getMessage()返回此 throwable 的详细消息字符串。

Throwable 类是 Java 语言中所有错误或异常的超类。

public void printStackTrace()将此 throwable 及其追踪输出至标准错误流

‘伍’ Java 异常中什么是显示堆栈轨迹

//方法出异常时会指明在那一行，显示异常的堆栈轨迹
try {
String s[]={"1"};
s[1]="abc";
} catch (Exception e) {
e.printStackTrace();
}

//
e.printStackTrace();
就是打印出异常堆栈信息，你也可以不调用此条语句。如：
try {
String s[]={"1"};
s[1]="abc";
} catch (Exception e) {
System.out.print("出错了"); }

‘陆’ java 面向对象异常问题

话不是这么说的，如果eclipse这么智能还要人干什么，

说简单点吧，如果按照你说的，比如现在eclipse都不报异常，有异常自动解决，

那如果现在我做一个工程，比如做运营商的系统，页面上如果有查询的输入值，但是对这个输入值做了前台校验，如果你输入的值是非法的，比如日期的格式规定的是2014/12/15这样的，那么你要是硬在页面输入2014*****dhefnak，反正就是一对乱七八糟的不合法的输入值，那么我可以把你的这个值获取到我的查询代码中，如果合法的话我返回给你一个正常的查询结果，但是如果不合法的值我获取到的话，那么执行到我的代码里面的话，我代码肯定会执行出错，那么这个时候页面理论上是要给客户一个出错提示框的，比如提示“输入格式不对，清重新输入”，那我就可以捕捉我的代码中的异常，用try｛｝catch（）｛｝来捕捉，捕捉到之后我定义我的错误信息，通过国际化定义好的常量，比如这个常量就是“输入格式不对，清重新输入”，然后返回这个异常到页面，客户就能看到了。

换句话说，如果代码自动识别你的错误输入，你输入错误的，我也给你一个正确的结果，这合理吗

哈哈，而且异常信息可以放到服务器的日志里，或者提示，我们开发人员很容易看出来，而且知道哪里有问题，帮助定位，如果都自动只能解决了，我要是不希望他在错误的时候干正确的事，或者他干的我不满意呢，我想按照自己的想发来定制就不行了，你输入1系统就认定是错的，2就是对的

如果按照你说的那样的话，我随便在京东或者淘宝，输入个什么，都成功进了别人的帐号，那咋办 出错的时候就要提示错误，开发人员可以捕捉到这种错误现实界面上客户能看懂的文件描述，这个系统可用性就很强了

我举了个简单的例子，很直白，不知道你理解没有，异常是有作用的，
出错也是代码的一部分，有的就该错，你觉得呢

‘柒’ 详细描述java是如何处理异常的

当出现程序无法控制的外部环境问题（用户提供的文件不存在，文件内容损坏，网络不可用...）时，JAVA就会用异常对象来描述。
JAVA中用2种方法处理异常：
1.在发生异常的地方直接处理；
2.将异常抛给调用者,让调用者处理。
JAVA异常可分为3种：
(1)检查性异常:java.lang.Exception
(2)运行期异常:java.lang.RuntimeException
(3)错误:java.lang.Error
顶层是java.lang.Throwable类，检查性异常，运行期异常，错误都是这个类的子孙类。
java.lang.Exception和java.lang.Error继承自java.lang.Throwable,而java.lang.RuntimeException继承自java.lang.Exception.
检查性异常------程序正确，但因为外在的环境条件不满足引发。例如：用户错误及I/O问题----程序试图打开一个并不存在的远程Socket端口。这不是程序本身的逻辑错误，而很可能是远程机器名字错误(用户拼写错误)。对商用软件系统，程序开发者必须考虑并处理这个问题。JAVA编译器强制要求处理这类异常，如果不捕获这类异常，程序将不能被编译。
运行期异常------这意味着程序存在bug，如数组越界，0被除，入参不满足规范.....这类异常需要更改程序来避免，JAVA编译器强制要求处理这类异常。
错误------一般很少见，也很难通过程序解决。它可能源于程序的bug，但一般更可能源于环境问题，如内存耗尽。错误在程序中无须处理，而有运行环境处理。
如何处理异常？
1.try...catch
程序运行产生异常时,将从异常发生点中断程序并向外抛出异常信息。
Java代码
int x = (int)(Math.random()*5);
int y = (int)(Math.random()*10);
int[] z =new int[5];
try
{
System.out.println("y/x="+(y/x));
System.out.println("y="+y+"z[y]="+z[y]);
}
catch (ArithmeticException exc1)
{
System.out.println("算术运算异常:"+exc1.getMessage());
}
catch ( exc2)
{
System.out.println("数据越界异常:"+exc2.getMessage());
}
说明:ArithmeticException和都属运行期异常：java.lang.RuntimeException，如果不用try...catch捕获，程序也是可通过编译的，但如果属于检查性异常：java.lang.Exception，必须而且一定要用try...catch...对其进行处理。
2.finally
如果把finally块置try...catch...语句后，finally块一般都会得到执行，它相当于一个万能的保险，即使前面的try块发生异常，而又没有对应异常的catch块，finally块将马上执行。
以下情形，finally块将不会被执行：
(1)finally块中发生了异常；
(2)程序所在线程死亡；
(3)在前面的代码中用了System.exit()；
(4)关闭CPU。
3.多个异常的处理规则：
定义多个catch可精确地定位异常。如果为子类的异常定义了特殊的catch块，而父类的异常则放在另外一个catch块中，此时，必须满足以下规则：子类异常的处理块必须在父类异常处理块的前面，否则会发生编译错误。所以，越特殊的异常越在前面处理，越普遍的异常越在后面处理。这类似于制订防火墙的规则次序：较特殊的规则在前，较普通的规则在后。
自己也可以定义并抛出异常，方法是2步：创建异常，抛出异常(首先实例化一个异常对象,然后用thow抛出)合在一起就是----
thow new IOException("异常说明信息")。将创建异常，抛出异常合在一起的好处是：创建异常时，会包含异常创建处的行信息，异常被捕获时可以通过堆栈迹(stack Trace)的形式报告这些信息。如果在同一行代码创建和抛出异常，对于程序的调试将非常有用。
所以，thow new XXX()已经成为一个标准的异常抛出范式。
在定义一个方法时，方法块中调用的方法可能会抛出异常，可用上面的thow new XXX()处理，如果不处理，那么必须在方法定义时，用thows声明这个方法会抛出的异常。
对异常的处理，有一条行之有效的默认规则：向上抛出-----被调用类在运行过程中对遇到的异常一概不作处理，而是直接向上抛出，一直到最上层的调用类，调用类根据应用系统的需求和特定的异常处理规则进行处理，如向控制台输出异常堆栈信息，打印在日志文件中。用一句形象的话来说，就是谁使用，谁(最上层的调用类)处理。

‘捌’ java中如果程序中报的异常是e,用代码来获得此异常的信息是

使用Exception类的成员方法printStackTrace() 可以将该异常的堆栈信息打印出来，因为堆栈信息中包含了抛出异常的代码所在的行，以及调用该行代码所在方法的代码所在的行，以此向上推，直到异常被捕获/虚拟机退出/到达调用结构最顶层，同时还能将异常的原因显示出来，因此能够通过e.printStackTrace() 快速了解异常产生的原因，以及产生异常的代码，进而解决问题。
建议楼主有时间了解一下java的异常捕获机制，这将对你深入java世界有很大的帮助。

‘玖’ 如何在程序异常退出前输出当前进程的堆栈信息 Backtraces

打印堆栈是调试的常用方法，一般在系统异常时，我们可以将异常情况下的堆栈打印出来，这样十分方便错误查找。实际上还有另外一个非常有用的功能：分析代码的行为。android代码太过庞大复杂了，完全的静态分析经常是无从下手，因此通过打印堆栈的动态分析也十分必要。

Android打印堆栈的方法，简单归类一下
1. zygote的堆栈mp
实际上这个可以同时mp java线程及native线程的堆栈，对于java线程，java堆栈和native堆栈都可以得到。
使用方法很简单，直接在adb shell或串口中输入：
[plain] view plain
kill -3 <pid>
输出的trace会保存在 /data/anr/traces.txt文件中。这个需要注意，如果没有 /data/anr/这个目录或/data/anr/traces.txt这个文件，需要手工创建一下，并设置好读写权限。
如果需要在代码中，更容易控制堆栈的输出时机，可以用以下命令获取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一样的。
不过需要注意两点：
adb shell可能会没有权限，需要root。
android 4.2中关闭了native thread的堆栈打印，详见 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆栈的打印被关掉了！不过对于大多数情况，可以直接将这个注释打开。

2. debuggerd的堆栈mp
debuggerd是android的一个daemon进程，负责在进程异常出错时，将进程的运行时信息mp出来供分析。debuggerd生 成的coremp数据是以文本形式呈现，被保存在 /data/tombstone/ 目录下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10个文件，当超过10个时，会覆盖重写最早生成的文件。从4.2版本开 始，debuggerd同时也是一个实用工具：可以在不中断进程执行的情况下打印当前进程的native堆栈。使用方法是:
[plain] view plain
debuggerd -b <pid>
这可以协助我们分析进程执行行为，但最最有用的地方是：它可以非常简单的定位到native进程中锁死或错误逻辑引起的死循环的代码位置。

3. java代码中打印堆栈
Java代码打印堆栈比较简单， 堆栈信息获取和输出，都可以通过Throwable类的方法实现。目前通用的做法是在java进程出现需要注意的异常时，打印堆栈，然后再决定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plain
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
当然也可以只打印堆栈不退出，这样就比较方便分析代码的动态运行情况。Java代码中插入堆栈打印的方法如下：
[java] view plain
Log.d(TAG,Log.getStackTraceString(new Throwable()));

4. C++代码中打印堆栈
C++也是支持异常处理的，异常处理库中，已经包含了获取backtrace的接口，Android也是利用这个接口来打印堆栈信息的。在Android的C++中，已经集成了一个工具类CallStack，在libutils.so中。使用方法：
[cpp] view plain
#include <utils/CallStack.h>
...
CallStack stack;
stack.update();
stack.mp();
使用方式比较简单。目前Andoid4.2版本已经将相关信息解析的很到位，符号表查找，demangle，偏移位置校正都做好了。
[plain] view plain

5. C代码中打印堆栈
C代码，尤其是底层C库，想要看到调用的堆栈信息，还是比较麻烦的。 CallStack肯定是不能用，一是因为其实C++写的，需要重新封装才能在C中使用，二是底层库反调上层库的函数，会造成链接器循环依赖而无法链接。 不过也不是没有办法，可以通过android工具类CallStack实现中使用的unwind调用及符号解析函数来处理。
这里需要注意的是，为解决链接问题，最好使用dlopen方式，查找需要用到的接口再直接调用，这样会比较简单。如下为相关的实现代码，只需要在要 打印的文件中插入此部分代码，然后调用getCallStack()即可，无需包含太多的头文件和修改Android.mk文件：
[cpp] view plain
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"

typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);

static void *gHandle = NULL;

static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];

unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;

// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);

// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");

if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}

count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);

for (i = 0; i < count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];

const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;

if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}

ALOGD("%s", line);
}

free_backtrace_symbols(symbols, count);

return result;
}
对sched_policy.c的堆栈调用分析如下,注意具体是否要打印，在哪里打印，还可以通过pid、uid、property等来控制一下，这样就不会被淹死在trace的汪洋大海中。
[plain] view plain
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)

6. 其它堆栈信息查询

‘拾’ 简述Java异常处理的过程

java中对处理异常有两个方法,一个是抛出异常,另一个是异常处理.
一 抛出异常
抛出异常就是在需要提示错误的时候,通过使用throw语句来抛出异常.例如:
int a = 1;
int b = 2;
if (a>b)
{
throw new Exception("a必须比b小");
}

二 异常处理
异常处理就是使用try catch语句对try块中包围的语句抛出的异常做处理,具体怎么处理要看业务需要.例如:
try
{
.....//try块包围的是一段需要处理的代码
}catch (Exception e)
{
e.printStackTrace();//catch块是对在try块中捕获的异常进行处理,这里是打印错误的堆栈信息
}

一个try块可以跟多个catch块,最后还有个finally块,用来执行try块做完之后需要执行的代码.例如:
try
{
.....
}catch (SQLException se)
{
se.printStackTrace();
}catch (FileNotFoundException fe)
{
fe.printStackTrace();
}catch (Exception e)
{
e.printStackTrace();
}finally
{
....
}