Exception Handling: Part 01 of 05

Part 1: Exception Handing Basics

Prelude

What better place to begin than one of the hottest areas of software development - exception handling! Just kidding, folks :o)

When I was a novice writing software, my supervisors had to force us newbies to put in exception handling. We thought of them as old fogies, with nothing better to do than make life miserable for us young people brimming with creativity and talent.

Life goes by and pretty soon one becomes an old fogey oneself. I haven't quite gotten there myself (yet), but I recently had the opportunity to revisit exception handling when some expensive code died without a stack-trace and I couldn't leave for the day until I got to the bottom of it. Unfortunately the entire application, developed by an out-sourcing firm, had been designed by some brilliant programmers who paid only a cursory nod to exception handling. That pretty much meant looking for a needle in a haystack everytime the code broke. Hacking into code. Putting in print statements. Uggh! (Now I realize why we need a a team of full-time experts dedicated exclusively to code maintenance.)

Thus begins the Exception Handling saga. In these 4 parts, I shall cover Exception handling in Perl from basic to best practices. Although this is a perl tutorial, you may find the concepts map to Java or any other programming language designed to make life interesting.

We'll start with the script (below). It opens a file 'secret.dat' which has but one word - the secret word. To read this secret word, the (default) main package has function 'outer' which calls 'inner1' which calls 'inner2' which calls 'inner3' where the file is opened with the native 'open' function.

Copy-Paste the script below into a file, say 'myLittleException01.pl'. The way this works is, you work through the catechism using the accompanying script in each of the parts 1 through 4 (See: "Follow me!" below). There, you're all set.

use strict;
$, = "\t", $\ = "\n";

my $fname = 'secret.dat';
my $secret;
eval {
  $secret = outer($fname);
};
if ($@) {
  print "Got e: $@";
}

print $secret;

sub outer {
  my $fname = shift;
  my $secret;
  $secret = inner1($fname);
  return $secret;
}

sub inner1 {
  my $fname = shift;
  my $secret;
  $secret = inner2($fname);
  return $secret;
}

sub inner2 {
  my $fname = shift;
  my $secret;
  $secret = inner3($fname);
  return $secret;
}

sub inner3 {
  die ("junk");
  my $fname = shift;
  my $secret;
  open(SECRET, "<$fname") || die ("Unable to open $fname");        
  $secret = < SECRET >;
  close(SECRET);
  return $secret;
}

Follow me!

1.
No exception handling:
Run the script without any exception handling;
Modify 'inner3' - remove 'die'.
2.
How to throw an exception?
In perl, 'die'; See 'inner3'.
3.
Now with 'die' in sub 'inner3' - run-time error, script exits with error message
4.
How to trap the exception for handling?
'eval' block and special variable '$@'
The error is trapped and message displayed (i.e. exception handled).
Note the use of special variable '$@'.
5.
What happens with two instances of 'die'?
Only the 1st exception is handled. Obvious?
7.
Drawbacks?
- In any software application, 'die' will be thrown from many places.
- STACK TRACE: How to trace through the maze of callers?
- - The application is a tree data-structure (DAG)
- - $@ - string-based exception-handling scheme
- - Exception handling by 'eval' block and $@ is limited.

You can see what basic facilities Perl offers for exception handling. And also how string-based exception handling is limited when it comes to software applications with a maze of interacting packages and external dependencies. There is no stack tracing which makes debugging a hit-and-miss. The sort of thing that keeps developers away from the arms of pretty girls (or boys, depending on gender and sexual orientation) and hastens the onset of burn-out.

Now let's make the world a little better place by putting in stack tracing. And since, ladies and gentlemen, we are fine programmers, let us first devise this stack-tracing contrivance ourselves.