A general rule of thumb when using some external library (which you always do in application programming, at least using the standard C library in C) is to check for failure of most functions you are calling.
A typical simple example is stdio(3) and <stdlib.h>
functions. You certainly should always check when using fopen(3) (or popen(3)) and malloc(3). So don't code
/// BAD SINCE NO CHECKS FILE* fil = fopen("outfile.txt", "w"); fprintf (fil, "something, e.g. one is %d\n", 1);
But at the very least:
FILE* fil = fopen("outfile.txt", "w"); if (!fil) { perror("fopen outfile.txt"); exit(EXIT_FAILURE); }; fprintf (fil, "something, e.g. one is %d\n", 1);
and likewise coding simply
/// BAD SINCE NO CHECKS struct somestruct_st *ptr = malloc(sizeof(struct somestruct_st)); ptr->somefield = 2;
is wrong, you should at least:
struct somestruct_st *ptr = malloc(sizeof(struct somestruct_st)); if (!ptr) { perror("malloc somestruct_st"); exit(EXIT_FAILURE); }; ptr->somefield = 2;
There are some functions which you could test but you often don't. A typical example is fclose(3). If you are very careful you should test it, but I usually don't.
Notice that testing corner cases failures (like above) may be hard. On Linux, lowering disk quotas and limits (with setrlimit(2) ...) may help, since you could almost force some of these failures.
Notice that server software (which runs many days) should take more care about detecting and reporting error than a simple commandline tool.
For critical embedded software (like your heart pacemaker, your airline aircraft) checking all cases is essential. static program analysis may help (but is not a silver bullet).
Also, study the source code of (and contribute to) existing free software. It will teach you a lot. And learn several programming languages (certainly Ocaml or Haskell, Scheme or CommonLisp will teach you a lot!).
Take also time to read the documentation of the functions or libraries that you are using.