In this case, the code is necessary.  In Java (which Processing is based on), it's possible to create functions/procedures that "throw errors" or "throw exceptions", meaning that if the function fails (typically due to a common occurrence like not finding a file), the function causes Java to spit out an error message and treat it as a special case.  Most library functions that involve I/O are designed to throw such exceptions.

In this case, if the function fails, you really need to know about it - you can't just blithely assume that the file was opened and a SamplePlayer was created - it'll fail if the file is missing, or you misspell the filename.  So the try/catch construct is intended for you to catch this situation.  You try the function out, and if it fails, you catch the error (the "exception") and you handle it gracefully (or ignore it, which is what it is happening in the above code).

When a function is declared to possibly throw an exception, you *have* to wrap it in a try/catch clause, the compiler won't let you completely ignore it - it wants to know that you are aware of the possibility for failure. You *do* have the option of ignoring the exception, as the above code does, and if you are running the code in a controlled environment, it's fine to do so.  However, it would be better to at least spit out some error text if the exception occurs, like so

1. try {  
2.     sp = new SamplePlayer(ac, new Sample(sourceFile));
3.   }
4.   catch(Exception e) {
5.    println("D00dz, problemz!!: " + e.getMessage());
6.   }
7.