[1] Aside from proofs-of-correctness; but there again, proofs-of-correctness never seem to be attached to anything longer than 10 lines anyway. The most basic run-time error is that the program refuses to execute at all. If you’ve been checking your program’s syntax with Perl’s -c switch, you might have a program that has no syntax errors but gives you the error “Permission denied” when you run it. This just means that you’re running on Unix and have not yet set the execute permission for your program. You might also get “Command not found” even though you can see the program is there! Relax; this just means you have a typo in the first line of your program (the #! or “shebang” line), and it’s saying it can’t find the program you’ve put there. Perhaps you typed prelinstead of perlagain (or left out the space before the -wflag, which this author just did). While we’re at it, you might also get an error looking like .nrecognized switch: -, which can drive you crazy until you discover that it’s from running a program with DOS-style line terminations on Unix. Remove the ^Ms with a tool like dos2unixor perl -pi.bak-e ’s/cM$//’. The distinction between an error and an exception may have been hitherto glossed over in this book, but at this point we need to make it clear. An error simply means that something went wrong; for instance, a system routine may return a value indicating that it can’t do what you have asked. A good program institutes some error handling at this point and checks the return code (more on this later). But the program is still running. An exception occurs (is “thrown,” in the lingo) when some code declares that something intolerable has happened and Perl is simply not going to allow your program to continue running unless you specifically know how to handle (or “catch”) the exception. At this point, your program could be in the middle of some arbitrarily deep nesting of subroutine calls and {}blocks. It ceases executing wherever it is, and starts to percolate back up this stack looking at each level for anything declared that could catch this exception. If it gets all the way to the top without finding such a handler, it executes a default exception handler, which in Perl’s case means printing a message with dieand exiting. Run-time exceptions from Perl may be built in, caused by usestrict, or generated by you. The -wflag can cause a run-time warning message to be displayed, but your program will continue executing. If you’ve followed good coding practices, you should be worried about this possibility, since it may indicate that Perl is working with bad data (data that should be defined but isn’t). If you want to make sure Perl halts when such a warning is generated, you can put this pseudo signal handler near the beginning of your program:[2] [2] This is one of the few times where the difference between warn and print STDERRbecomes apparent; the former is trapped by this sort-of signal handler, the latter is not. local $SIG{__WARN__} = sub { die $_[0] } and Perl exits after printing the warning. 9.1 Symbolic References Now that you’re putting use strictin all of your programs, let’s look at the class of runtime exceptions it can generate. One instance is from the use of symbolic references.
Note: If you are looking for good and quality webspace to host and run your java application check Actions java hosting services