OK, I will make all the changes on default.

You are right to remind me to avoid these kinds of last minute changes no matter how safe they seem.

The patch I posted in comment #12 is a step in the right direction and the problem with many test failures related to MException when running the test suite appears to be solved now.

However, I noticed that the Matlab docs say that any code that detects an error and throws an exception creates an MException object.  My patch doesn't quite do that.  Instead, we generate some internal exception object and then convert it to an MException object when executing "CATCH (OBJ)" blocks are executed.  That's probably OK (does it matter to the user when the MException object is actually created?) but then if the CATCH block does something like

catch (obj)
  obj.addCause (...);
  obj.addCorrection (...);
  rethrow (obj);
end

then the extra info added to the MException object OBJ is lost because internally, Octave doesn't handle that info.

I can fix that, but it is a larger change than I'd like to do for Octave 8.

I see at least three options:

1. Defer all MException changes to the default branch.
2. Add MException.m on stable but don't change the way that throwing and catching errors work, so for CATCH (OBJ), OBJ will still be a simple struct.
3. Add MException.m and apply my change from comment #12 on stable so that for CATCH (OBJ), OBJ will be an MException object.  But (re)throwing an MException object may lose extra "cause" and "correction" info.

Any preference about what to do?  I lean toward the third option with a note about the missing features in the NEWS file and possibly a warning from the MException throw and rethrow methods when the object contains extra cause or correction info that will be lost.

Thanks for your comments. Regarding the `sprintf` call, I just checked with Matlab and the behavior differs from `error`:

>> MException ("octave:bug", "error message %s")

ans =

  MException with properties:

    identifier: 'octave:bug'
       message: 'error message '
         cause: {}
         stack: [0x1 struct]
    Correction: []

>> sprintf("error message %s")

ans =

    "error message "

>> error("error message %s")
error message %s

I will look into preparing a patch.

An exhaustive search in github/gnu-octave returns a few more hits but no compatibility issue when replacing the struct with a MException from what I can see:

https://github.com/gnu-octave/octave/blob/f0aa1b51b22bf2bb7781a3c1fc6d2e41faf8a668/test/bug-61201.tst#L51
https://github.com/gnu-octave/octave/blob/75b9445a76e6c0c6537bb46fd5eb7eeb0cb5cfec/scripts/general/integral.m#L137
https://github.com/gnu-octave/octave/blob/f0aa1b51b22bf2bb7781a3c1fc6d2e41faf8a668/scripts/miscellaneous/version.m#L104
https://github.com/gnu-octave/packages/blob/0c498a330b0a2caa1a738d6c2ab78dfadacfdb54/assets/ci/octave_ci.m#L83
https://github.com/gnu-octave/octave/blob/75b9445a76e6c0c6537bb46fd5eb7eeb0cb5cfec/scripts/geometry/delaunayn.m#L80
https://github.com/gnu-octave/pkg-apa/blob/aedc7b8c8625f2852b129e2b84250d216c4fde85/inst/test_apa.m#L450
https://github.com/gnu-octave/statistics/blob/ee4b64ebc570f16220ecd1af4ef4e524fece0de6/inst/violin.m#L136

from your comment #13, is the only thing that seems to be needed is slightly modifying jwe's comment #10 patch with " setting back setAccess = private to hasBeenCaught" ? or were there other problems that needed to be corrected before being pushed out for testing?

Re-assigning to dev.

@Guillaume: Yes, I forgot to include the small change I made to your MException.m:

This part changes it to set hasBeenCaught to true if the constructor is called with 2 arguments.  Maybe I should have used the value of the second argument, but I just needed to set hasBeenCaught to true.

--- MException.m        2021-12-28 09:18:56.304544115 -0500
+++ MException.m        2021-12-28 09:57:26.453914848 -0500
@@ -47,11 +47,16 @@
   methods (Access = public)

     function this = MException (id, template, varargin)
-      if (nargin == 1 && isstruct (id))
-        # Matlab does not have this constructor. Used internally by last().
+      if ((nargin == 1 || nargin == 2) && isstruct (id))
+        # Matlab does not have this constructor. Used internally by
+        # last() and by the evaluator in constructing exception
+        # objects in CATCH blocks.
         this.identifier = id.identifier;
         this.message = id.message;
         this.stack = id.stack;
+        if (nargin == 2)
+          this.hasBeenCaught = true;
+        endif
       else
         if (nargin < 2 || nargout > 1)
           print_usage ();

I also needed this change to accept Octave's error identifiers that include '-' characters:

--- MException.m        2021-12-28 09:18:56.304544115 -0500
+++ MException.m        2021-12-28 09:57:26.453914848 -0500
@@ -65,7 +70,10 @@
       if (! ischar (this.message) || (! isempty (this.message) && ! isrow (this.message)))
         error ("MException: Message must be a row string.");
       endif
-      if (! isempty(this.identifier) && isempty (regexp(this.identifier,'^([a-zA-Z]\w*)(:[a-zA-Z]\w*)+$')))
+      if (! isempty (this.identifier)
+          && isempty (regexp (this.identifier,
+
+                              "^([A-Za-z][A-Za-z)-9_-]*)(:[A-Za-z][A-Za-z0-9_-]*)*$")))
         error ("MException: Invalid identifier.");
       endif
     endfunction

When we get this working it would probably be best to find a way to construct the MException object without needing to evaluate a function so that Octave will always correctly construct these objects even if the MException function is shadowed by some user-defined function.  I mean, I assume that Matlab doesn't call a user-defined MException constructor if it happens to appear somewhere in the the path, right?

I hoped to integrate MException in the Octave evaluator before now.  But at this point it does seem better to postpone this feature until version 8.

If you want to experiment with it, the attached change will make CATCH blocks create MException objects instead of simple structs.  This change is simple enough but there are many test failures related to MException when running the test suite after this change.  It seems that Octave is failing to find the MException constructor.  I'm not sure what triggers that.  There was some discussion of a similar problem in bug #60791 but the patch posted there did not solve the problem for me.



(file #52580)

Is this really blocking the Octave 7 release? What minimum steps would be necessary to get this ready for Octave 7?

My question for getReport() was to know whether there would be a way to capture the text that is sent to std::cerr in libinterp/corefcn/error.cc: error_system::display_exception (const execution_exception& ee) so that it can be returned as a string instead of raising an exception.

Thanks, it seems the MException class doesn't do much - it's mainly a wrapper around built-in rethrow () defined for structs. For the getReport method, I would need the output of rethrow () as a string, would there be a way to get access to that?

In Matlab, rethrow () only works in the context of "try/catch ME" so the ME object in that instance should have a private flag hasBeenCaught set to true so that we can reproduce the same behavior. Do we need to define an accessor to set that property or could the code defining "try/catch ME" do that directly?

I also notice that, when run twice, "test MException" will return an error:

class not found: MException

It doesn't seem to be specific to this class (i.e. handling of errors). I'll try to come up with a small class reproducing the issue.

(file #52136)

I am looking at MException objects and this seems to be the only open bug report referencing them: would it make sense starting an implementation of a classdef-based MException class?

https://www.mathworks.com/help/matlab/ref/mexception.html

Then "try, catch ME" could be modified to return an MException object instead of a struct.

Following up on https://savannah.gnu.org/bugs/?func=detailitem&item_id=33217 , Octave doesn't recognize functions such as throw and rethrow used in Matlab's new exception handling syntax.

[cf. http://www.mathworks.com/help/matlab/matlab_prog/capture-information-about-errors.html for Matlab's documentation]