HttpSession session = request.getSession();
session.addAttribute("key","value");
[download]

Guildenstern writes:

I'm not sure if Perl supports error handling in the same manner (try and catch, or similar), but I'm sure somebody here can clue me in.

darobin mentions this below - use eval BLOCK with die to catch and throw exceptions:

eval {
   # code that might die
};

if ($@) {
   # $@ contains your exception
}
[download]

Peace,
-McD

Update: merlyn is right, of course - forgot the ";". Curse my flying fingers! :-)

eval { 
   # code that might die 
} 
 
if ($@) { 
   # $@ contains your exception 
}
[download]

Don't forget the semicolon after the eval {}. That kind of eval is an expression, not a statement, so it needs a semicolon to become a statement.

-- Randal L. Schwartz, Perl hacker

Each tool has its merits, even if it only serves as a bad example :-)

I think that if you learn more different languages, you have more tools available to you to tackle the problems you'll encounter. One major point I find in Java programming is the pattern-orientedness of the algorithms / classes implemented in Java; my experience with Java is, that people there tend to document which Programming Pattern they applied to solve a certain problem, be it the Visitor pattern (an object iterates over a collection of other objects, and "visits" each element) or the Observer pattern (an object registers itself with another object and is then notified of changes within that other object). It's easy to implement these patterns elsewhere, but Java people seem (to me at least) to be more educated about patterns.

I see that you are already good at comparing Java with Perl and at finding the Perl way and Java way to express what you want to accomplish. This is what speaking languages is really about, expressing the same thing in different ways, only that Java is more roundabout in IO tasks than Perl.

To show you a small thing which is easy in Java but hard in Perl, have a look at threads. Java (and the underlying JVM) has threading built in, together with semaphors (called "monitors" AFAIR). This makes threads ubiquituous in Java, while they are virtually non-existent in Perl.

In any event, I hope Java replaces C++ entirely. We've had that abomination for far too long. But Java won't replace Perl, any more than Perl replaces C++.

-- Randal L. Schwartz, Perl hacker

Just curious: what makes Java only "hybrid-OO"? I haven't dabbled with Java for many, many years*, so I don't recall too much about it...

*I was excited when I first heard about Java, and searched hard before I found what was apparently the /only/ book on the market about it, that was heavy on the buzzwords and light on the examples. Kind of lost interest after that. Now there's whole sections in bookstores devoted to it. Must have been a sign to focus on Perl. :)

Java has "primitive types" that cannot be subclassed nor extended.

Smalltalk has no such artificial distinction.

Java proponents claim that you must have primitive types to get decent performance. Odd, because Sun's Java VM itself is primarily written in Self, which has no primitive types (in fact, it doesn't even have classes!).

-- Randal L. Schwartz, Perl hacker

Corion's right, every tool has its merits and its idiosyncrasies. A simple idiom in one will turn into a tortured mess in another. A key, I think, is to learn what each does well and then leverage those strengths. At the very least, the additional exposure will help round out your skills. In turn, this should help round out your resumé and fatten your wallet in the long run.

Since you're still getting started in this wonderful discipline (and hopefully making a little more than you used to), allow me to recommend two books that may help you get a good start (and contribute to the Monastery's Treasury, should you purchasing using the links.)

• The Pragmatic Programmer
• Code Complete

While the latter is getting a bit dated, it still contains very useful information.

--f

try
    {
      FileInputStream inStream = new FileInputStream( args[0] );
      inStream = ("myFile.txt");
    }
    catch(IOException ioerr)
    {
      System.out.println( ioerr.toString() );
    }
[download]

open(FH,"myFile.txt") or die "Nope : $!\n";
[download]

die "Nope : $!\n" unless open(FH,"myFile.txt");
[download]

if (not open FH, 'myFile.txt')
{
    print STDERR "Nope : $!\n";
    exit;
}
[download]

!open FH => 'myFile.txt' == 0 && die "Nope : $!\n";
[download]

Each and every one of these languages has it's place and purpose. When I first started to pick up Perl, I really struggled with writing it. "What do you mean it it figures out if it's a string or an integer?!" That's a really tough concept to find peace with when your pervious language of choice was C. The layers of abstraction were a little more acceptable with something like VB since it seemed like a toy language anyway. BUT.. even VB has it's place.

I promised a point, right?

I guess the point is that even though you may love Perl, learn what you can of other languages. My least favorite language is probably Java for it's slowness.. and don't talk about compiled java because then it just looses it's whole damn purpose in the furst place. But it still has it's place too. It's another tool.. and programming is about "programming", not about which language you use. Design is the key.. and you choose the language to meet the needs. You're not going to use Java or Perl for RTOS programming.. and you're not (or shouldn't) use C to do some simple one liner shell script. And even though I'd love to.. I'm not going to pump perl out to thousands of Wintel desktops so I can write login scripts in Perl instead of batch files or vbscript/jscript. OK.. maybe I would if we were still left with just batch files but..

Anyway.. to make a short point longer, Java is just another tool. Tools are good. And even bad tools teach you something.

Actually, open(FH,"myFile.txt") or die "Nope : $!\n"; isn't really equivalent to the try-catch part above. A closer moral equivalent would be:

eval {
    open FH, '<my_file' or die $!;
};
print $@ if $@;
[download]

...or of course a number of other possible Perl constructs around the same idea.

-- darobin

I know how you feel. I work for a company that has aspirations of being a "Java only" shop. Each week in our status meetings, they request things and the lead says it absolutely can't be done in under 3 weeks...I quietly go back to my cube, sit down at the machine, and script it in perl in less than a day.

Java is good for some things......Perl is good for many things ;-).

You make a good point azatoth, but I believe .. as others have already commented on that that each language has it's uses/pros/cons. At the company where I am now, we primilary use Perl for parsing(tis excellent) and a bit of database programming. We're just starting to use weblogic with Java - jsp - for our new web application projects. I like you, just took a Java course - although this was a bit intense for 5 days (it was a sun certified course - oddly enough not one student was planning on taking the exam), it went through OOP and many of it's advantages, as well as Java and it's many uses. I won't discuss it here, it's not really the place - but I can definately appreciate perl's simpleness and ease of use after taking the course - although I liked the freedom that a developer is given with Java and it's event handling, interfaces, inner classes, etc. But, to reiterate - I think Perl is great because one doesn't have to go through such lengthy syntax to produce the same output as Java.