Re: try/catch not swallowing errors

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Rik-4
On 04/13/2019 05:38 AM, [hidden email] wrote:
Subject:
Package showing error message even when caught
From:
Daniel Kraft [hidden email]
Date:
04/13/2019 04:25 AM
To:
Octave Maintainers List [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
Message-ID:
[hidden email]
Content-Type:
multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ExXGeCnwrVMVHcBpTr1CB6XKd8uNy6r2J"
Message:
2

Hi!

I just noticed something weird:  With the code below, the error message
generated by "fload" for reading from an EOF stream ("could not read
binary header") is printed even though the error is caught (although
execution continues without an error being flagged, which is correct).
The Octave documentation for try-catch clearly states that also error
messages are not printed.

pkg load parallel;
try
  [r, w] = pipe ();
  fclose (w);
  fload (r);
catch
end_try_catch

If I use "error" directly in the try-catch block or even if using a
simple .oct file that just creates an error, then no message is printed
as expected.  But with the error generated from the parallel package's
"fload", it *is* shown.  So maybe it is related to the error being
thrown from out of a package?

I see this both on Octave 4.0.3 and 5.1.

Is this expected behaviour or a bug?
This looks like something worth investigating.

I used this test code in a file tst_try.m

function tst_try
  try
    subfcn1 ();
  catch
  end_try_catch
endfunction

function subfcn1
  error ("Throw an error in subfcn1");
endfunction

When run, the error in the subfunction is not displayed.  Hence, I don' think the error in fload should be displayed either.

You might try debug_on_error (1) and inspect where the error is being generated.  Maybe the code uses printf rather than error or something like that.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Daniel Kraft
Hi Rik!

On 13.04.19 17:14, Rik wrote:

> On 04/13/2019 05:38 AM, [hidden email] wrote:
>> I just noticed something weird:  With the code below, the error message
>> generated by "fload" for reading from an EOF stream ("could not read
>> binary header") is printed even though the error is caught (although
>> execution continues without an error being flagged, which is correct).
>> The Octave documentation for try-catch clearly states that also error
>> messages are not printed.
>>
>> pkg load parallel;
>> try
>>   [r, w] = pipe ();
>>   fclose (w);
>>   fload (r);
>> catch
>> end_try_catch
>
> This looks like something worth investigating.
>
> I used this test code in a file tst_try.m
>
> function tst_try
>   try
>     subfcn1 ();
>   catch
>   end_try_catch
> endfunction
>
> function subfcn1
>   error ("Throw an error in subfcn1");
> endfunction
>
> When run, the error in the subfunction is not displayed.  Hence, I don'
> think the error in fload should be displayed either.
Yes, that's what I would expect.  I also tried doing what you did with a
custom .oct file, but the error was still not displayed in that case for me.

> You might try debug_on_error (1) and inspect where the error is being
> generated.  Maybe the code uses printf rather than error or something
> like that.

As far as I can tell, this is where the error is generated:

https://sourceforge.net/p/octave/parallel/ci/default/tree/src/fload.cc#l53

That looks correct to me.  When I do exactly the same (use error() in
C++) in an .oct file of mine, it works, though.  That's why I guess it
could be related to packages somehow.

Yours,
Daniel

--
https://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz
To go: Arc-Cav-Hea-Kni-Mon-Tou


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Mike Miller-4
On Sat, Apr 13, 2019 at 17:24:19 +0200, Daniel Kraft wrote:
> That looks correct to me.  When I do exactly the same (use error() in
> C++) in an .oct file of mine, it works, though.  That's why I guess it
> could be related to packages somehow.

I think it may be more specific than that. Can you try the same example,
but call 'fload' with an invalid file descriptor? I tried that and the
error message was suppressed, and shows up with 'lasterror'.

    try
      fload (99);
    catch
    end_try_catch

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Rik-4
In reply to this post by Rik-4
On 04/13/2019 09:00 AM, [hidden email] wrote:
Subject:
Re: try/catch not swallowing errors
From:
Daniel Kraft [hidden email]
Date:
04/13/2019 08:24 AM
To:
[hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] <MTAwMDAyMi5ub21hZA.1555168472@quikprotect>
In-Reply-To:
<MTAwMDAyMi5ub21hZA.1555168472@quikprotect>
Message-ID:
[hidden email]
Content-Type:
multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4njGAyKc9Dlw0AISOmhhuGmoPJzBm2xIH"
Message:
2

Hi Rik!

On 13.04.19 17:14, Rik wrote:
On 04/13/2019 05:38 AM, [hidden email] wrote:
I just noticed something weird:  With the code below, the error message
generated by "fload" for reading from an EOF stream ("could not read
binary header") is printed even though the error is caught (although
execution continues without an error being flagged, which is correct).
The Octave documentation for try-catch clearly states that also error
messages are not printed.

pkg load parallel;
try
  [r, w] = pipe ();
  fclose (w);
  fload (r);
catch
end_try_catch
This looks like something worth investigating.

I used this test code in a file tst_try.m

function tst_try
  try
    subfcn1 ();
  catch
  end_try_catch
endfunction

function subfcn1
  error ("Throw an error in subfcn1");
endfunction

When run, the error in the subfunction is not displayed.  Hence, I don'
think the error in fload should be displayed either.
Yes, that's what I would expect.  I also tried doing what you did with a
custom .oct file, but the error was still not displayed in that case for me.

I verified with a .oct file as well and also got no printed error.

        
You might try debug_on_error (1) and inspect where the error is being
generated.  Maybe the code uses printf rather than error or something
like that.
As far as I can tell, this is where the error is generated:

https://sourceforge.net/p/octave/parallel/ci/default/tree/src/fload.cc#l53

That looks correct to me.  When I do exactly the same (use error() in
C++) in an .oct file of mine, it works, though.  That's why I guess it
could be related to packages somehow.
It must be something else in either the parallel or the struct package.  I tried to install the parallel package, but it required struct, and I was unable to install struct.

CXXFLAGS="-O2 -pipe -Wno-deprecated-declarations" /usr/local/bin/mkoctfile-5.1.0 --verbose -c error-helpers.cc
g++ -c  -fPIC -I/usr/local/include/octave-5.1.0/octave/.. -I/usr/local/include/octave-5.1.0/octave -I/usr/local/include  -pthread -fopenmp -O2 -pipe -Wno-deprecated-declarations    error-helpers.cc -o error-helpers.o
In file included from error-helpers.cc:22:0:
error-helpers.h:31:22: error: ‘octave_execution_exception’ does not name a type; did you mean ‘make_execution_exception’?
 void c_verror (const octave_execution_exception&, const char *, ...);
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
                      make_execution_exception
error-helpers.cc:36:17: error: ‘octave_execution_exception’ does not name a type; did you mean ‘make_execution_exception’?
 c_verror (const octave_execution_exception&, const char *fmt, ...)
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
                 make_execution_exception
error-helpers.cc: In function ‘void _p_error(const char*, ...)’:
error-helpers.cc:60:8: error: ‘cerr’ is not a member of ‘std’
   std::cerr << msg;
        ^~~~
error-helpers.cc:60:8: note: suggested alternative: ‘errc’
   std::cerr << msg;
        ^~~~
        errc
Makefile:40: recipe for target 'error-helpers.o' failed
make: *** [error-helpers.o] Error 1
make: Leaving directory '/tmp/oct-gRP2yg/struct-1.0.15/src'

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Daniel Kraft
In reply to this post by Mike Miller-4
Hi mike!

On 13.04.19 21:38, Mike Miller wrote:

> On Sat, Apr 13, 2019 at 17:24:19 +0200, Daniel Kraft wrote:
>> That looks correct to me.  When I do exactly the same (use error() in
>> C++) in an .oct file of mine, it works, though.  That's why I guess it
>> could be related to packages somehow.
>
> I think it may be more specific than that. Can you try the same example,
> but call 'fload' with an invalid file descriptor? I tried that and the
> error message was suppressed, and shows up with 'lasterror'.
>
>     try
>       fload (99);
>     catch
>     end_try_catch
Interesting!  For me, that code does indeed also not give an error.

(I originally found this because my real code uses try-catch with fload
to handle EOF conditions.)

Yours,
Daniel

--
https://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz
To go: Arc-Cav-Hea-Kni-Mon-Tou


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Daniel Kraft
In reply to this post by Rik-4
Hi Rik!

On 14.04.19 06:13, Rik wrote:

> On 04/13/2019 09:00 AM, [hidden email] wrote:
>> As far as I can tell, this is where the error is generated:
>>
>> https://sourceforge.net/p/octave/parallel/ci/default/tree/src/fload.cc#l53
>>
>> That looks correct to me.  When I do exactly the same (use error() in
>> C++) in an .oct file of mine, it works, though.  That's why I guess it
>> could be related to packages somehow.
>
> It must be something else in either the parallel or the struct package. 
> I tried to install the parallel package, but it required struct, and I
> was unable to install struct.
I ran into these issues as well, they are fixed in the repositories of
struct/parallel already (so I was able to install both packages from
their source repositories fine on 5.1).

Yours,
Daniel

--
https://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz
To go: Arc-Cav-Hea-Kni-Mon-Tou


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

John W. Eaton
Administrator
On 4/14/19 12:47 AM, Daniel Kraft wrote:

> Hi Rik!
>
> On 14.04.19 06:13, Rik wrote:
>> On 04/13/2019 09:00 AM, [hidden email] wrote:
>>> As far as I can tell, this is where the error is generated:
>>>
>>> https://sourceforge.net/p/octave/parallel/ci/default/tree/src/fload.cc#l53
>>>
>>> That looks correct to me.  When I do exactly the same (use error() in
>>> C++) in an .oct file of mine, it works, though.  That's why I guess it
>>> could be related to packages somehow.
>>
>> It must be something else in either the parallel or the struct package.
>> I tried to install the parallel package, but it required struct, and I
>> was unable to install struct.
>
> I ran into these issues as well, they are fixed in the repositories of
> struct/parallel already (so I was able to install both packages from
> their source repositories fine on 5.1).
Maybe I'm using the wrong repo or something, but I was unable to install
the parallel package.  I am using the sources found here

   http://hg.code.sf.net/p/octave/parallel

at HG ID

   97770ea46e93 tip

I executed make dist in the top-level directory to generate
target/parallel-3.1.3.tar.gz.  Attempting to install that with Octave
5.1.0, I see the errors in the attached log file.

Can you post exactly how you are building these package?

I can't be sure until I can try to run some tests, but looking at the
sources for the parallel package, I suspect the problem is due to code
that is attempting to cope with various changes in Octave internals
related to error handling and that the code in the package is not doing
the right thing now.

jwe


typescript (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Olaf Till-2
On Sun, Apr 14, 2019 at 08:38:11AM -0400, John W. Eaton wrote:
> Maybe I'm using the wrong repo or something, but I was unable to install the
> parallel package.  I am using the sources found here
>
>   http://hg.code.sf.net/p/octave/parallel
>
> at HG ID
>
>   97770ea46e93 tip

Seems they have lost the last 5 changesets at sourceforge some days
ago. Similar things happened before for other packages (they installed
an old backup after having a repository corruption, they said).

I've restored the 5 changesets plus a 6th one. With those,
installation of tip should work.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Olaf Till-2
In reply to this post by John W. Eaton
On Sun, Apr 14, 2019 at 08:38:11AM -0400, John W. Eaton wrote:
> On 4/14/19 12:47 AM, Daniel Kraft wrote:
> > On 14.04.19 06:13, Rik wrote:
> > > It must be something else in either the parallel or the struct package.

It's something within the parallel package, and it affects the optim
and database packages as well.

In my attempts to stay compatible with different ways of Octave
versions to handle errors, I somehow came to use, among others, a
function which directly writes to standard error. I just didn't think
of 'lasterror' and 'try/catch'...

I had never noticed the issue, but it was probably already present in
previous versions of the said packages, with Octave versions <5.1. Do
you think we should stop the pending releases of optim and database
until the issue is fixed?

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: try/catch not swallowing errors

Daniel Kraft
Hi!

On 14.04.19 15:45, Olaf Till wrote:

> On Sun, Apr 14, 2019 at 08:38:11AM -0400, John W. Eaton wrote:
>> On 4/14/19 12:47 AM, Daniel Kraft wrote:
>>> On 14.04.19 06:13, Rik wrote:
>>>> It must be something else in either the parallel or the struct package.
>
> It's something within the parallel package, and it affects the optim
> and database packages as well.
>
> In my attempts to stay compatible with different ways of Octave
> versions to handle errors, I somehow came to use, among others, a
> function which directly writes to standard error. I just didn't think
> of 'lasterror' and 'try/catch'...
Ah ok, I see.  That makes sense!

> I had never noticed the issue, but it was probably already present in
> previous versions of the said packages, with Octave versions <5.1. Do
> you think we should stop the pending releases of optim and database
> until the issue is fixed?

I don't know if that question was directed at me, but IMHO that is just
a minor issue.  I just wondered about it because my usage (while working
on modernising the level-set package) suddenly showed that error
message.  It doesn't really affect anything for me, so from my point of
view, it is certainly not critical.

Yours,
Daniel

--
https://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz
To go: Arc-Cav-Hea-Kni-Mon-Tou


signature.asc (849 bytes) Download Attachment