Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Using exception

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: Guillaume Rousse <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] Using exception
  • Date: Mon, 07 Oct 2013 17:55:54 +0200

Le 04/10/2013 05:01, IKEDA Soji a écrit :
I'm still convinced than we have other priorities than switching error
handling to exceptions all over the place right now. And a limited usage
of them would probably help figuring out how they work exaclty.

If you use exception in limited usage, you would better propose
coding rule of yours.
Replace every occurence of
if ($condition) {
log_error_message("foobar");
return undef;
}

By:

croak "foobar" if $condition;

And deal with exception somewhere upstream, in order to keep exception usage confined in specific part of Sympa code, and won't disturb the rest of the code.

That's simple, and allows a progressive transition from current error handling system, which works perfectly, in favor of another, in a controlled manner.

Here is the revised rule of mine. There are some notes after it.

* To throw exception, do:

die Sympa::Exception::Foo->new(Message => 'error occurred');
Technically more complex than:

croak 'error occurred';

without immediate added value. That breaks KISS principle.

* To catch exception, do as below:

# "try" block
eval {
# *1
# Here is the code probably throws exception
# *2
};

# "catch" block
if (ref $@ eq 'Sympa::Exception::Foo') {

# process exception

} elsif (ref $@ eq 'Sympa::Exception::Bar') {

# process another exception

}
# We have responsibility to re-throw exceptions we won't catch.
elsif ($@) {
die $@;
}

* If processing at (*1) requires clean-up at (*2), make sure that
such clean-up will be done even when exception was thrown.


Notes (this is not part of rule):

- croak() appends to argument the filename and line number where it
is called.
die() doesn't, if the argument ends with "\n".
If argument is reference, both functions won't modify it.

So, we may use die() to throw and to re-throw exceptions.

- The function blessed() suggested by Guillaume is useful, but it
is provided by external package Scalar::Util.
It is part of Core.

So tests on exception objects might be done using built-in ref().

- Exception which programmer doesn't wish to catch must be
re-thrown. This is the primary rule.

Since programmers cannot be responsible to the exceptions they
don't expect, they should not cancel such ones but should pass
to higher levels.


Again: Is the rule above easy enough to keep?
That's reasonably easy, at least for anyone understanding implementation details of exceptions handling in Perl. I'm not sure we all are equals in this regard.

Anyway, that's still uselessly complex for me, especially with a lack of discussion about the exact needs, and the expected benefits over current system.

Hence my point: to be discussed later, once we have a working code base, on specific use case.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31


Attachment: smime.p7s
Description: Signature cryptographique S/MIME




Archive powered by MHonArc 2.6.19+.

Top of Page