LINUX C没有try catch吗

Unix（包括Linux）下的C语言编程中是不会使用try catch的，的确C也没有这个语法。然而当运行时的错误异常被抛出时，系统会产生信号发送给进程，如果进程没有做信号响应函数的话，就会被中断运行并且产生core文件，通过core文件可以查看程序的崩溃原因、当时的调用堆栈、当时的变量值等等信息，当然这是另外一个话题。

因此在Unix下，与try catch起到相似作用的东西就是信号相应函数。相关的使用方法大体包括如下内容：

1、信号安装

signal()

sigaction()

2、发送信号函数

int raise(int sig)

int pause(void)

int kill(pid_t pid,int sig)

unsigned int alarm(unsigned int seconds)

int sigqueue(pid_t pid,int sig,const union sigval val)

int setitimer(int which,const struct itimerval *value,struct itimerval *oldvalue)

void abort(void)

3、信号集及信号集 *** 作

sigfillset(sigset_t *set)

sigemptyset(sigset_t *set)

sigaddset(sigset_t *set,int sig)

sigdelset(sigset_t *set,int sig)

4、阻塞信号相关函数

int sigprocmask(int how,const sigset_t *set,sigset_t *set)

int sigpending(sigset_t *set)

int sigsuspend(const sigset_t *set)

具体使用方法可参考相应文档

Linux下编程（尤其是服务端程序）若由于内存越界或其他原因产生“非法 *** 作”，会导致程序悄无声息地死去，初学者往往不知道程序死掉的原因。本人也曾饱受程序死不瞑目之苦。其实“非法 *** 作”在绝大多数时候是因为“段错误”，即 SIGSEGV。而找到SIGSEGV信号抛出的位置，也就找到了程序死掉的原因。

下面列出一些捕获SIGSEGV的方法。

假设程序名为 myprg，其进程ID(pid)为 2032。方法一：

# ./myprg // 运行程序

# ps -ef | grep myprg // 找出 myprg 的 pid

# gdb myprg 2032 >debug.log // 让 gdb 接管 myprg 的运行

# (gdb) continue

此方法利用gdb调试器捕获SIGSEGV。上例中，将gdb输出信息存入debug.log，关闭终端，gdb并不退出，继续运行直到 myprg 出错退出。gdb将捕获到出错点。方法二：

# ./myprg // 运行程序

# Segment fault (core dumped) // 程序死掉了，系统输出 "Segment fault"

# gdb myprg core // 用 gdb 分析 core 文件

此方法利用core文件，进行事后分析。但前提是保证系统会生成core文件。

# ulimit -a

查看当前core文件大小的限制，若为0，则需将它改为unlimited。

# ulimit -S -c unlimited

或修改 /etc/profile，找到 unlimit -S -c 0，将0改为unlimited，重启系统。

另外，如果程序安装了 SIGSEGV 异常处理函数，那么 gdb myprg core 时显示的并不是真实的出错位置，要想看到真实的出错点，必须暂时去掉异常处理函数。

---