in reply to Tutorial: Introduction to Object-Oriented Programming

    1. It is considered bad form for an object to die(). There are many reasons for this, but the most important one is that you cannot know every context in which your class might be used -- you might think that being unable to establish a database connection is worth dieing for, but what if I rewrote your script to try to use the database first and then fall back on a plain file if I couldn't establish a connection. Normally, the right thing to do is to set a flag and highlight the fact in the documentation that the user should check the flag before assuming that everything is ok.

I don't agree with this statement: die in an class/object method can be viewed as throwing an exception which can be caught by an eval {...}; block. It is the responsibility of the programmer using the class to catch the exceptions. This is the way things work in Java and I rather appreciate it.

On the other hand, die is not sufficiently expressive to do the job, so if your intention is to point people to using the Exception or the Class::Exception modules, I couldn't agree more.

Or it could be that I completely miss your point...

Just my 2 cents, -gjb-

In Section Meditations