Re^2: Using die() in methods

Oh, yes, that's exactly why I use die() only in object-builders, because I have a habit to new() through eval(). I've got this habit, because a certain number of other people's classes sometimes could die() in the builder().

But I think the descision to die() can have only the main module. Subroutines call other subroutine, if someone have an error occuried - okay, let them to return the special sign to the caller and the caller will report to its' caller and so on - until the process pop up to the main module. And the main module sends the long error message to the error stream: "Can't sub1(): Can't sub2(): Can't sub3(): Can't open connect to the database: ...".

I've made a tricky Error-class for my own usage. It has the method error(), when I call it with some parameter, it stores this parameter as the error message and returns undef, so I can do return($self->error("Something bad has happened")) and the caller will get undef. When it gets the undef value, it checks for $caller->has_error(). So I can be sure whenever the method has got an error or it just doesn't find any records in the database.

It's not worse than try/catch, but it let other people to call methods of my classes without being afraid to die().

V.Melnik

Comment on Re^2: Using die() in methods

Replies are listed 'Best First'.
Re^3: Using die() in methods by tobyink (Canon) on Jul 09, 2014 at 22:33 UTC
You wrote: "okay, let them to return the special sign to the caller and the caller will report to its' caller and so on - until the process pop up to the main module." But perhaps you might have said instead: "let them to return the special sign to the caller and the caller will report to its' caller and so on - until it reaches a level I forgot to check for the special sign." Exceptions are a special sign. But they are a special sign that you cannot forget to pass to your caller because Perl automatically passes it up and up and up until it finds a caller that is willing to do something useful with the special sign (i.e. catch the exception). So throw exceptions! Don't return special signs! If every level of caller needs knowledge about your "special signs", then your callers have too much knowledge about your class. Your callers have become tightly coupled to your class. This is bad. "But I think the descision to die() can have only the main module." I think you're confusing the decision to `die()` with the decision to `exit()`. I absolutely agree that the main script should be making the decision about when it exits. However, as you know, calling `die()` does not necessarily cause the script to exit; it can be caught by any level of caller and handled gracefully. It only causes the script to exit if an error occurs that nothing is able to handle. toby döt ink	[reply] [d/l] [select]
Re^3: Using die() in methods by boftx (Deacon) on Jul 08, 2014 at 02:37 UTC
Do not fear death, you will re-awaken to a world built with Perfect Perl 7 and no Python. You must always remember that the primary goal is to *drain the swamp* even when you are hip-deep in alligators.	[reply]