Bug #78224 for Log-Report: Log::Report uses exit not die

Thu Jul 05 13:44:08 2012 chm [...] cpan.org - Ticket created

CC:	Mark [...] Overmeer.net
Subject:	Log::Report uses exit not die

It appears that Log::Report will actually call exit
within an error reporter if the interpreter state is
not $^S as true.

This is problematic for users of this module since
there is no way from perl to "handle" a live exit call.
An error failure should not lead to an exit unless
the user has requested error and exit. See the
problem report for Geo::KML leading to this report.

--Chris

Thu Jul 05 15:51:38 2012 Mark [...] Overmeer.net - Correspondence added

Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 21:51:22 +0200
To:	Chris Marshall via RT <bug-Log-Report [...] rt.cpan.org>
From:	Mark Overmeer <mark [...] overmeer.net>

* Chris Marshall via RT (bug-Log-Report@rt.cpan.org) [120705 18:06]: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 > > > It appears that Log::Report will actually call exit > within an error reporter if the interpreter state is > not $^S as true. > > This is problematic for users of this module since > there is no way from perl to "handle" a live exit call. > An error failure should not lead to an exit unless > the user has requested error and exit. See the > problem report for Geo::KML leading to this report.

You are totally mistaken. It is very normal for a "die" to terminate the program with an exit unless within an eval... the same for "error" in Log::Report: it will exit unless in an eval (indicated by $^S) So: error handling via Log::Report's error() works the same as via die(). They both have the same mechanism to catch it: eval{} As I explained before. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

Thu Jul 05 15:51:39 2012 The RT System itself - Status changed from 'new' to 'open'

Thu Jul 05 16:23:24 2012 devel.chm.01 [...] gmail.com - Correspondence added

CC:	chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 16:23:15 -0400
To:	bug-Log-Report [...] rt.cpan.org
From:	Chris Marshall <devel.chm.01 [...] gmail.com>

On Thu, Jul 5, 2012 at 3:51 PM, Mark Overmeer via RT <bug-Log-Report@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 > > > * Chris Marshall via RT (bug-Log-Report@rt.cpan.org) [120705 18:06]:

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 > >> >> It appears that Log::Report will actually call exit >> within an error reporter if the interpreter state is >> not $^S as true. >> >> This is problematic for users of this module since >> there is no way from perl to "handle" a live exit call. >> An error failure should not lead to an exit unless >> the user has requested error and exit. See the >> problem report for Geo::KML leading to this report.

> > You are totally mistaken. It is very normal for a "die" to terminate > the program with an exit unless within an eval... the same for "error" > in Log::Report: it will exit unless in an eval (indicated by $^S) > > So: error handling via Log::Report's error() works the same as via > die(). They both have the same mechanism to catch it: eval{} > As I explained before.

From perldoc -f exit: ... Don't use "exit" to abort a subroutine if there's any chance that someone might want to trap whatever error happened. Use "die" instead, which can be trapped by an "eval". ... I know what Log::Report is _trying_ to do but the scheme to determine if one is in an eval gives a different result than perl by itself. This can be demonstrated by replacing the exit in the routine by a die which is the recommended style per the above excerpt, and that works as expected inside an eval and inside the Devel::REPL shell. Given that exit *can never be caught at the perl level* it is not useful for any type of embedded functionality as it will kill perl itself. In my experience, a direct exit is only useful if you have control of the entire program being run and not just a sub being called. This is either a bug at the Geo::KML level since it is not calling Log::Report within an eval to catch the exception and thus allowing an exit call from the interpreter, or a bug in Log::Report resulting from using exit rather than the recommended die. I think a fix at the lower level would be cleaner and simpler. --Chris

Thu Jul 05 16:33:21 2012 Mark [...] Overmeer.net - Correspondence added

CC:	chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 22:33:06 +0200
To:	"devel.chm.01 [...] gmail.com via RT" <bug-Log-Report [...] rt.cpan.org>
From:	Mark Overmeer <mark [...] overmeer.net>

* devel.chm.01@gmail.com via RT (bug-Log-Report@rt.cpan.org) [120705 20:23]: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 >

> >From perldoc -f exit:

> ... > Don't use "exit" to abort a subroutine if there's any chance > that someone might want to trap whatever error happened. Use > "die" instead, which can be trapped by an "eval". > ... > > I know what Log::Report is _trying_ to do but the scheme > to determine if one is in an eval gives a different result than > perl by itself. This can be demonstrated by replacing the > exit in the routine by a die which is the recommended style > per the above excerpt, and that works as expected inside > an eval and inside the Devel::REPL shell.

Log::Report is implementing a more sophisticated system of exceptions than perl's print/warn/die. So, it is very understandable that it does call exit(), not die(). Ever tried to let die() end a problem with a nice RC? Show quoted text

> Given that exit *can never be caught at the perl level* it is > not useful for any type of embedded functionality as it will > kill perl itself. In my experience, a direct exit is only > useful if you have control of the entire program being run > and not just a sub being called.

The exit in Log::Report::report() is only called when we really want the program to stop, just like die() outside eval(). I know that modules should not exit, but Log::Report is an alternative for CORE features ... that has different rules. Show quoted text

> This is either a bug at the Geo::KML level since it is not > calling Log::Report within an eval to catch the exception > and thus allowing an exit call from the interpreter,

No. The program using Geo::KML cannot continue because the module gets XML which is does not understand. Say, you are reading from a CSV file with 10 fields per line. The program finds a line with only 2 fields. What would you do? Die or return undef? The main program will not be able to continue anyway. Show quoted text

> or > > a bug in Log::Report resulting from using exit rather than > the recommended die. I think a fix at the lower level > would be cleaner and simpler.

You can simply say: my $data = try { Geo::KML->readFrom($file) }; die $@ if $@;

Thu Jul 05 16:54:16 2012 devel.chm.01 [...] gmail.com - Correspondence added

CC:	"devel.chm.01 [...] gmail.com via RT" <bug-Log-Report [...] rt.cpan.org>, chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 16:54:05 -0400
To:	Mark Overmeer <mark [...] overmeer.net>
From:	Chris Marshall <devel.chm.01 [...] gmail.com>

On Thu, Jul 5, 2012 at 4:33 PM, Mark Overmeer <mark@overmeer.net> wrote: Show quoted text

> * devel.chm.01@gmail.com via RT (bug-Log-Report@rt.cpan.org) [120705 20:23]:

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 >

>> >From perldoc -f exit:

>> ... >> Don't use "exit" to abort a subroutine if there's any chance >> that someone might want to trap whatever error happened. Use >> "die" instead, which can be trapped by an "eval". >> ... >> >> I know what Log::Report is _trying_ to do but the scheme >> to determine if one is in an eval gives a different result than >> perl by itself. This can be demonstrated by replacing the >> exit in the routine by a die which is the recommended style >> per the above excerpt, and that works as expected inside >> an eval and inside the Devel::REPL shell.

> > Log::Report is implementing a more sophisticated system of > exceptions than perl's print/warn/die. So, it is very understandable > that it does call exit(), not die(). Ever tried to let die() end a > problem with a nice RC?

I'm not sure what an RC is but calling exit essentially puts a stop to any possible perl operations past that point in the code. I don't know of any cases where calling exit from perl is a good approach unless you are controlling the entire application/program and you really want to stop everything in its tracks with no possible recovery. Show quoted text

>> Given that exit *can never be caught at the perl level* it is >> not useful for any type of embedded functionality as it will >> kill perl itself. In my experience, a direct exit is only >> useful if you have control of the entire program being run >> and not just a sub being called.

> > The exit in Log::Report::report() is only called when we really > want the program to stop, just like die() outside eval(). I know > that modules should not exit, but Log::Report is an alternative > for CORE features ... that has different rules.

Since replacing exit with die makes the error work the same way as perl, it is arguable that something is different between your detection of when a user cares about handling failures and when it is ok to destroy/kill/terminate/exit...the entire perl interpreter and the program instead. Show quoted text

>> This is either a bug at the Geo::KML level since it is not >> calling Log::Report within an eval to catch the exception >> and thus allowing an exit call from the interpreter,

> > No. The program using Geo::KML cannot continue because the module > gets XML which is does not understand. Say, you are reading from > a CSV file with 10 fields per line. The program finds a line with > only 2 fields. What would you do? Die or return undef? The main > program will not be able to continue anyway.

That is the problem with exiting. There is no way for any other level of code to handle the situation further. In this case, I'm in a REPL loop command shell and *definitely* don't want perl to exit just because an XML file has bad data. Show quoted text

>> or >> >> a bug in Log::Report resulting from using exit rather than >> the recommended die. I think a fix at the lower level >> would be cleaner and simpler.

> > You can simply say: > > my $data = try { Geo::KML->readFrom($file) }; > die $@ if $@;

This is the first file IO routine that I have seen that kills perl rather than returning some sort of status or exception. I saw nothing in the Geo::KML docs to suggest that an eval is needed to keep perl alive after trying to read a KML file. At the least, please document your recommended usage so folks will know the danger and how to work around the problem. I'm sorry I don't know more about why the check for $^S fails in this case. I do know that $^S is undef when you call exit in my case. If you checked for defined() first and then hand off to exit, I think that would work around the crash in the REPL for me. At least I can work around the issue going forwards. Regards, Chris

Thu Jul 05 17:21:29 2012 devel.chm.01 [...] gmail.com - Correspondence added

CC:	chm [...] cpan.org, Mark [...] overmeer.net
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 17:21:19 -0400
To:	bug-Log-Report [...] rt.cpan.org
From:	Chris Marshall <devel.chm.01 [...] gmail.com>

Well, I re-re-read the description of $^S and caught: $EXCEPTIONS_BEING_CAUGHT $^S Current state of the interpreter. $^S State --------- ------------------- undef Parsing module/eval true (1) Executing an eval false (0) Otherwise The first state may happen in $SIG{__DIE__} and $SIG{__WARN__} handlers. Where the key observation is that $^S can take on the undef value in parsing an _eval_ so that the exit usage would be correct if you do check that $^S is defined and false before calling exit. I still think it would be simpler/safe to use die directly. Cheers, Chris On Thu, Jul 5, 2012 at 4:54 PM, devel.chm.01@gmail.com via RT <bug-Log-Report@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 > > > On Thu, Jul 5, 2012 at 4:33 PM, Mark Overmeer <mark@overmeer.net> wrote:

>> * devel.chm.01@gmail.com via RT (bug-Log-Report@rt.cpan.org) [120705 20:23]:

>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 >

>>> >From perldoc -f exit:

>>> ... >>> Don't use "exit" to abort a subroutine if there's any chance >>> that someone might want to trap whatever error happened. Use >>> "die" instead, which can be trapped by an "eval". >>> ... >>> >>> I know what Log::Report is _trying_ to do but the scheme >>> to determine if one is in an eval gives a different result than >>> perl by itself. This can be demonstrated by replacing the >>> exit in the routine by a die which is the recommended style >>> per the above excerpt, and that works as expected inside >>> an eval and inside the Devel::REPL shell.

>> >> Log::Report is implementing a more sophisticated system of >> exceptions than perl's print/warn/die. So, it is very understandable >> that it does call exit(), not die(). Ever tried to let die() end a >> problem with a nice RC?

> > I'm not sure what an RC is but calling exit essentially > puts a stop to any possible perl operations past that > point in the code. I don't know of any cases where > calling exit from perl is a good approach unless you > are controlling the entire application/program and you > really want to stop everything in its tracks with no > possible recovery. >

>>> Given that exit *can never be caught at the perl level* it is >>> not useful for any type of embedded functionality as it will >>> kill perl itself. In my experience, a direct exit is only >>> useful if you have control of the entire program being run >>> and not just a sub being called.

>> >> The exit in Log::Report::report() is only called when we really >> want the program to stop, just like die() outside eval(). I know >> that modules should not exit, but Log::Report is an alternative >> for CORE features ... that has different rules.

> > Since replacing exit with die makes the error > work the same way as perl, it is arguable that > something is different between your detection > of when a user cares about handling failures and > when it is ok to destroy/kill/terminate/exit...the > entire perl interpreter and the program instead. >

>>> This is either a bug at the Geo::KML level since it is not >>> calling Log::Report within an eval to catch the exception >>> and thus allowing an exit call from the interpreter,

>> >> No. The program using Geo::KML cannot continue because the module >> gets XML which is does not understand. Say, you are reading from >> a CSV file with 10 fields per line. The program finds a line with >> only 2 fields. What would you do? Die or return undef? The main >> program will not be able to continue anyway.

> > That is the problem with exiting. There is no way for > any other level of code to handle the situation further. > In this case, I'm in a REPL loop command shell and > *definitely* don't want perl to exit just because an XML > file has bad data. >

>>> or >>> >>> a bug in Log::Report resulting from using exit rather than >>> the recommended die. I think a fix at the lower level >>> would be cleaner and simpler.

>> >> You can simply say: >> >> my $data = try { Geo::KML->readFrom($file) }; >> die $@ if $@;

> > This is the first file IO routine that I have seen > that kills perl rather than returning some sort > of status or exception. > > I saw nothing in the Geo::KML docs to suggest > that an eval is needed to keep perl alive after > trying to read a KML file. At the least, please > document your recommended usage so folks > will know the danger and how to work around > the problem. > > I'm sorry I don't know more about why the check > for $^S fails in this case. I do know that $^S is > undef when you call exit in my case. If you > checked for defined() first and then hand off to > exit, I think that would work around the crash > in the REPL for me. > > At least I can work around the issue going > forwards. > > Regards, > Chris >

Thu Jul 05 17:58:02 2012 Mark [...] Overmeer.net - Correspondence added

CC:	"devel.chm.01 [...] gmail.com via RT" <bug-Log-Report [...] rt.cpan.org>, chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 5 Jul 2012 23:57:45 +0200
To:	Chris Marshall <devel.chm.01 [...] gmail.com>
From:	Mark Overmeer <mark [...] overmeer.net>

* Chris Marshall (devel.chm.01@gmail.com) [120705 20:54]: Show quoted text

> > my $data = try { Geo::KML->readFrom($file) }; > > die $@ if $@;

> > This is the first file IO routine that I have seen that kills perl > rather than returning some sort of status or exception.

Traditional modules in Perl do not use exception mechanisms. If they have such mechanisms, than I expect they will also die on fatal exceptions which are not caught. Show quoted text

> I saw nothing in the Geo::KML docs to suggest > that an eval is needed to keep perl alive after > trying to read a KML file. At the least, please > document your recommended usage so folks > will know the danger and how to work around > the problem.

I do not see how people would be able to implement a generic work-around for file-formats which are not supported. Show quoted text

> I'm sorry I don't know more about why the check > for $^S fails in this case. I do know that $^S is > undef when you call exit in my case. If you > checked for defined() first and then hand off to > exit, I think that would work around the crash > in the REPL for me.

According to perlvar/EXCEPTIONS_BEING_CAUGHT, "undef" means: error during compilation of the code. I think defined($^S) will not work, because we need to stop the program on compilation errors as well. I will check this... currently on holidays... so will take some time. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions drs Mark A.C.J. Overmeer MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net

Thu Jul 05 19:59:01 2012 devel.chm.01 [...] gmail.com - Correspondence added

CC:	"devel.chm.01 [...] gmail.com via RT" <bug-Log-Report [...] rt.cpan.org>, chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Thu, 05 Jul 2012 19:58:49 -0400
To:	Mark Overmeer <mark [...] overmeer.net>
From:	chm <devel.chm.01 [...] gmail.com>

On 7/5/2012 5:57 PM, Mark Overmeer wrote: Show quoted text

> * Chris Marshall (devel.chm.01@gmail.com) [120705 20:54]:

>>> my $data = try { Geo::KML->readFrom($file) }; >>> die $@ if $@;

>> >> This is the first file IO routine that I have seen that kills perl >> rather than returning some sort of status or exception.

> > Traditional modules in Perl do not use exception mechanisms. If they > have such mechanisms, than I expect they will also die on fatal exceptions > which are not caught.

Correct, but the problem is that the current default kills perl without the ability to recover. It is ok for that to be the implementation you choose but it needs to be documented so folks can work around the death of the interpreter. The perl read builtin does not die if it fails, just returns undef: Show quoted text

> read FILEHANDLE,SCALAR,LENGTH,OFFSET > read FILEHANDLE,SCALAR,LENGTH > Attempts to read LENGTH characters of data into variable SCALAR > from the specified FILEHANDLE. Returns the number of > characters actually read, 0 at end of file, or undef if there > was an error (in the latter case $! is also set). SCALAR will > be grown or shrunk so that the last character actually read is > the last character of the scalar after the read. > > An OFFSET may be specified to place the read data at some place > in the string other than the beginning. A negative OFFSET > specifies placement at that many characters counting backwards > from the end of the string. A positive OFFSET greater than the > length of SCALAR results in the string being padded to the > required size with "\0" bytes before the result of the read is > appended. > > The call is actually implemented in terms of either Perl's or > system's fread() call. To get a true read(2) system call, see > "sysread". > > Note the characters: depending on the status of the filehandle, > either (8-bit) bytes or characters are read. By default all > filehandles operate on bytes, but for example if the filehandle > has been opened with the ":utf8" I/O layer (see "open", and the > "open" pragma, open), the I/O will operate on UTF-8 encoded > Unicode characters, not bytes. Similarly for the ":encoding" > pragma: in that case pretty much any characters can be read.

Show quoted text

>> I saw nothing in the Geo::KML docs to suggest >> that an eval is needed to keep perl alive after >> trying to read a KML file. At the least, please >> document your recommended usage so folks >> will know the danger and how to work around >> the problem.

> > I do not see how people would be able to implement a generic > work-around for file-formats which are not supported.

The problem isn't whether you can anticipate every possible use of the modules, just that the current implementation prevents any possible use outside the scope you have envisioned. In my case, if the file is bad, I can ask for another file. At the least, I would like the perl shell (a.k.a. the REPL to keep running)... Show quoted text

>> I'm sorry I don't know more about why the check >> for $^S fails in this case. I do know that $^S is >> undef when you call exit in my case. If you >> checked for defined() first and then hand off to >> exit, I think that would work around the crash >> in the REPL for me.

> > According to perlvar/EXCEPTIONS_BEING_CAUGHT, "undef" means: error > during compilation of the code. > > I think defined($^S) will not work, because we need to stop the > program on compilation errors as well. I will check this... > currently on holidays... so will take some time.

Again, the approach appears to be kill perl if you think something is wrong rather than letting the user of your modules make that determination. I'm just pointing out why some users might need a different implementation and how it might be done. Unfortunately, I'm not enough of a perl5-porter to understand or explain why $^S could be undef when it *is* being run in an eval structure somewhere. The current approach makes Log::Report pretty much unusable for a my application(s) since in general I try to localize the exception handling as much as possible rather than having to wrap every line with try {} catch {}. It needs to be documented at the least. I appreciate the dialog. Have a good holiday. --Chris

Fri Jul 06 09:59:01 2012 chm [...] cpan.org - Correspondence added

On Thu Jul 05 19:59:01 2012, devel.chm.01@gmail.com wrote:
Show quoted text

> On 7/5/2012 5:57 PM, Mark Overmeer wrote:

> >
> > According to perlvar/EXCEPTIONS_BEING_CAUGHT, "undef" means: error
> > during compilation of the code.

I read perlvar/EXCEPTIONS_BEING_CAUGHT as
undef means we are parsing a module or eval *and*
that the undef may also occur in $SIG{__DIE__} and
$SIG{__WARN__} handlers.

Show quoted text

> > I think defined($^S) will not work, because we need to stop the
> > program on compilation errors as well. I will check this...
> > currently on holidays... so will take some time.

This is not a compile time error in Geo::KML which
is using Log::Report and the exit here is not because
of a perl compile/syntax problem.

I tried this on a win32 Strawberry Perl Portable install
v5.16.0 and saw the identical behavior so the issue
is not v5.10.1 specific (cygwin has an old perl). The
simplest way to reproduce exactly my test case, just
install Devel::REPL and run the re.pl shell script.
Then:

$ use Geo::KML
$ my ($ns,$data) = Geo::KML->from('a_kml_data_file.kml')
<boom>

Back to your command prompt, le perl est mort.

Fri Jul 06 10:00:29 2012 chm [...] cpan.org - Correspondence added

On Fri Jul 06 09:59:01 2012, CHM wrote:
Show quoted text

> On Thu Jul 05 19:59:01 2012, devel.chm.01@gmail.com wrote:

> > On 7/5/2012 5:57 PM, Mark Overmeer wrote:

> > >
> > > According to perlvar/EXCEPTIONS_BEING_CAUGHT, "undef" means: error
> > > during compilation of the code.

>
> I read perlvar/EXCEPTIONS_BEING_CAUGHT as
> undef means we are parsing a module or eval *and*
> that the undef may also occur in $SIG{__DIE__} and
> $SIG{__WARN__} handlers.
>

> > > I think defined($^S) will not work, because we need to stop the
> > > program on compilation errors as well. I will check this...
> > > currently on holidays... so will take some time.

>
> This is not a compile time error in Geo::KML which
> is using Log::Report and the exit here is not because
> of a perl compile/syntax problem.
>
> I tried this on a win32 Strawberry Perl Portable install
> v5.16.0 and saw the identical behavior so the issue
> is not v5.10.1 specific (cygwin has an old perl). The
> simplest way to reproduce exactly my test case, just
> install Devel::REPL and run the re.pl shell script.
> Then:
>
> $ use Geo::KML
> $ my ($ns,$data) = Geo::KML->from('a_kml_data_file.kml')
> <boom>
>
> Back to your command prompt, le perl est mort.

Where a_kml_data_file.kml should be a one that
fails to load so the $stop code is called.

Fri Jul 06 16:01:21 2012 Mark [...] Overmeer.net - Correspondence added

Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Fri, 6 Jul 2012 22:01:05 +0200
To:	"devel.chm.01 [...] gmail.com via RT" <bug-Log-Report [...] rt.cpan.org>
From:	Mark Overmeer <mark [...] overmeer.net>

* chm (devel.c hm.01@gmail.com) [120705 23:58]: Show quoted text

> Correct, but the problem is that the current default kills perl without > the ability to recover.

It seems that you are not reading my responses. You are totally Mistake. I will try it for a last time (let's hope the coin drops) This way you avoid Perl to be killed and implement recovery: use Log::Report qw/error try/; my $r = try { error "crash" }; try() is a smart eval() Show quoted text

> The perl read builtin does not die if it fails, just returns undef:

Of course, because read() is an abstraction level lower. And read() of Perl is not in the simplistic exception model. Log::Report implements an exception model. In Java, for instance, readLine() does throw an IOException, which is an exit when not caught. Show quoted text

> The problem isn't whether you can anticipate every > possible use of the modules, just that the current > implementation prevents any possible use outside > the scope you have envisioned.

Geo::KML is a "Final" module with respect to parsing the KML files, not meant to be extended. (I really do not see any real-life purpose for that.) And you can always catch() as in any Exception model. Show quoted text

> In my case, if the file is bad, I can ask for another > file. At the least, I would like the perl shell (a.k.a. > the REPL to keep running)...

So, wrap try() around it. Show quoted text

> try {} catch {}. It needs to be documented at > the least.

If you wish. In this respect you have a point: the synopsis tell us that failure is reported as simple "undef" on the namespace... but that's only for a subset of problems. In general, Perl programmers know that they can wrap "die()s" with evals, which works here as well. Log::Report::try() is a bit more powerful in this particular case. Many modules carp() and confess() where you have to eval them as well. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions drs Mark A.C.J. Overmeer MARKOV Solutions http://Mark.Overmeer.net http://solutions.overmeer.net

Fri Jul 06 21:22:06 2012 devel.chm.01 [...] gmail.com - Correspondence added

CC:	chm [...] cpan.org
Subject:	Re: [rt.cpan.org #78224] Log::Report uses exit not die
Date:	Fri, 06 Jul 2012 21:21:53 -0400
To:	bug-Log-Report [...] rt.cpan.org
From:	chm <devel.chm.01 [...] gmail.com>

On 7/6/2012 4:01 PM, Mark Overmeer via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78224 > > > * chm (devel.c hm.01@gmail.com) [120705 23:58]:

>> Correct, but the problem is that the current default kills perl without >> the ability to recover.

> > It seems that you are not reading my responses. You are totally > Mistake. I will try it for a last time (let's hope the coin drops)

I think we disagree on the "benefit" of calls to exit from perl modules from a software reuse point of view. Show quoted text

> This way you avoid Perl to be killed and implement recovery:

I have already explained that I don't want to special-case wrap things in extra evals so that exit won't be called. Show quoted text

> > use Log::Report qw/error try/; > my $r = try { error "crash" }; > > try() is a smart eval()

The Devel::REPL is running its code in an eval but I realized that since it uses Moose stuff with all the meta-object abstractions---that implementation happens at compile time (which is how undef can be returned in $^S. Show quoted text

>> The perl read builtin does not die if it fails, just returns undef:

> > Of course, because read() is an abstraction level lower. And read() of > Perl is not in the simplistic exception model. Log::Report implements > an exception model. In Java, for instance, readLine() does throw an > IOException, which is an exit when not caught.

Apparenty, Log::Read requires one to use its own try mechanism as it apparently ignores plain perl eval in some cases (unfortunately the one I have). Show quoted text

>> The problem isn't whether you can anticipate every >> possible use of the modules, just that the current >> implementation prevents any possible use outside >> the scope you have envisioned.

> > Geo::KML is a "Final" module with respect to parsing the KML files, > not meant to be extended. (I really do not see any real-life purpose > for that.) And you can always catch() as in any Exception model. >

>> In my case, if the file is bad, I can ask for another >> file. At the least, I would like the perl shell (a.k.a. >> the REPL to keep running)...

> > So, wrap try() around it.

I have already explained that I don't want to special-case wrap things in extra evals so that exit won't be called. Show quoted text

>> try {} catch {}. It needs to be documented at >> the least.

> > If you wish. In this respect you have a point: the synopsis tell > us that failure is reported as simple "undef" on the namespace... > but that's only for a subset of problems. > > In general, Perl programmers know that they can wrap "die()s" with > evals, which works here as well. Log::Report::try() is a bit more > powerful in this particular case. Many modules carp() and confess() > where you have to eval them as well.

If by "powerful" you mean "fatal in some cases", yes. I've managed to convince myself that I understand why $^S was undef for my Devel::REPL and still be in an evident eval. (See the Devel::REPL source for details). I still believe that Log::Report would be a more powerful and useful module if it did not exit the perl interpreter (perhaps unless requested by the use-er). Regards and thanks for the Geo::KML and contributing to perl. Regards, Chris

Tue Aug 28 03:13:52 2012 MARKOV [...] cpan.org - Correspondence added

User mistaken

Tue Aug 28 03:13:53 2012 MARKOV [...] cpan.org - Status changed from 'open' to 'rejected'