bugGNU Octave - Bugs: bug #59592, using std::exception to catch...

 
 

bug #59592: using std::exception to catch errors

Submitter:  None
Submitted:  Wed 02 Dec 2020 08:02:30 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 6.1.0
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 03 Dec 2020 02:09:57 AM UTC, comment #7: 

Regarding comment #2 . What is the drawback of publicly inheriting from std::exception! :) I have found this post https://softwareengineering.stackexchange.com/a/305642 useful. The whole point is that we wish to see Octave staying in the highest possible state. Thanks for fixing!.

Anonymous
Wed 02 Dec 2020 10:30:24 PM UTC, comment #6: 

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Wed 02 Dec 2020 10:19:37 PM UTC, comment #5: 

OK, seems fine to me.  I imported the changeset on stable, merged with default, and pushed.

Thanks.

John W. Eaton <jwe>
Group administrator
Wed 02 Dec 2020 10:09:04 PM UTC, comment #4: 

I don't think it breaks ABI.  Some new functions might be available that were hidden before, but that is an allowable change for an ABI.  It does not appear to me to change the return type or input type of any parameters nor parameter ordering.

A changeset against stable is attached.  It works for me and "make check" passes.

(file #50384)

Rik <rik5>
Group administrator
Wed 02 Dec 2020 09:29:56 PM UTC, comment #3: 

Yeah, I'm pretty sure it was just a mistake to not use public inheritance.

Does changing the inheritance from private to public change the ABI?  I don't think it does, and if I'm right about that, then it is a trivial change to make for the 6.2 bug-fix release.

John W. Eaton <jwe>
Group administrator
Wed 02 Dec 2020 09:11:11 PM UTC, comment #2: 

I can see that this would be easy to resolve.  It may have even been an oversight not to "public"ly inherit from std::runtime_error.  I've CC'ed jwe who did the work on this to review that question.

But, I do wonder how critical it is to fix this.  When coding for Octave, such as an octfile, a C++ programmer has access to all the functions and data types that Octave itself has.  Since this is a try block for Octave code, why not catch an Octave exception rather than catching the generic C++ exception?  For example, the following works:


  catch (const octave::execution_exception& e)


Is there some benefit that I'm not seeing for catching the more general parent class of std::exception?

Rik <rik5>
Group administrator
Wed 02 Dec 2020 08:04:48 AM UTC, comment #1: 

The file bug_59592.cc is attached  .

(file #50371)

Anonymous
Wed 02 Dec 2020 08:02:30 AM UTC, original submission:  

Thankfully in Octave 6.1 all exception types are refactored to inherit ,directly or indirectly, from std::exception but it may need some modification to be used in the following situation. Consider the following example:


try
  {
    error ("some error");
  }
catch (const std::exception& e)
  {
    std::cout << "can be caught with std::exception\n" ;
  }
catch (...)
  {
    std::cout << "cannot be caught with std::exception\n" ;
  }


Someone may want to throw an error and use std::exception to catch it but currently it is impossible because the exception liboctave/util/quit.h is defined as :


class execution_exception : std::runtime_error


This StackOverflow post https://stackoverflow.com/a/8152888/6579744 recommends to define it as


class execution_exception : public std::runtime_error


Thanks!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50384:  bug59592.cset added by rik5 (813B - application/octet-stream)
file #50371:  bug_59592.cc added by None (403B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-02 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2020-12-02 rik5 Attached File- Added bug59592.cset, #50384
        StatusNeed Info Patch Submitted
    2020-12-02 rik5 StatusNone Need Info
        Carbon-Copy- Added jwe
    2020-12-02 None Attached File- Added bug_59592.cc, #50371

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code