OpProp is a procedure. Procedures have last-name-eval, so when you invoke just,
   lastexception;
you just get the expression sequence containing the literal name OrProp. But when you do
   print(lastexception);
you are requesting more (depending on the value of interface(verboseproc) at the time).

You could also compare the behaviour for,
   lastexception[1];
versus,
   eval(lastexception[1]);
and,
   print(OrProp);
It is unusual, that the last example immediately above also shows the issue.

In the CommandLine interface your code results in the body of OrProp being printed to the terminal. It's not that long.

I don't know yet why the Java GUI thinks that it has to elide altogether the printing of OrProp as a procedure. But I notice a discrepency between the results from,
   printf("%P",eval(OrProp));
and that of,
   showstat(OrProp);
around the code line numbers 52 and 53. It might be related.

But it's stranger because the behavior you've mentioned doesn't seem to depend on the setting of interface(verboseproc) .

I know that you are interested in using timelimit. You could try something like this, instead,

   print(sprintf("%a",lastexception[1]),
            StringTools:-FormatMessage(lastexception[2..-1]));

I mentioned that last bit as I suspect you might not be fully satisfied with the results from your suggestion,
   StringTools:-FormatMessage(lastexception)

Other useful tools include stopat, trace, and showstat.

For example, using trace (after using stopat and showstat to discover the computation path),

Download dsolve_traced.mw

I suspect that it happens because of the following.

restart;

trace(`simpl/simpl/Re/is`):
#stopat(`simpl/simpl/Re/is`):

Re(x) assuming {};

{--> enter \`simpl/simpl/Re/is\`, args = \`x~\`
                x2 := x

<-- exit \`simpl/simpl/Re/is\` (now in \`simpl/simpl/Re\`) = 0}
                   0

Note that when you enter
    ... assuming {}
the assuming facility temporarily places that property on dependent names. So your call amounts to supplying the property x::{} . So the result is the same as this,

Re(x) assuming x::{};
{--> enter \`simpl/simpl/Re/is\`, args = \`x~\`
                x2 := x

<-- exit \`simpl/simpl/Re/is\` (now in \`simpl/simpl/Re\`) = 0}
                   0

If you follow that procedure in the debugger you can see these checks (which I compare against the case of the unassumed name):

restart;
is(x2,'real');
                 false

restart;
is(x2,'real') assuming x2::{};
                  true

# the previous true induces this test
(not type(x2,'complexcons')
     or `property/ProbablyNonZero`(x2) <> true)
and traperror(is(x2,0)) assuming x2::{};
                  true

# perhaps of particular interest
is(x2,0) assuming x2::{};
                  true

is(x2,0);
                false

You can run it through and see what happens (ie. at lines 4 and 5, say),

showstat(`simpl/simpl/Re/is`);

`simpl/simpl/Re/is` := proc(x)
local x2;
   1   if hastype(x,'float') and not type(x,'complex(numeric)') and type(
         x,'complexcons') then
   2       x2 := `simpl/simpl/ReIm/is/float`(x)
       else
   3       x2 := x
       end if;
   4   if (not type(x2,'complexcons') or has(x2,'RootOf') or 
         `property/ProbablyNonZero`(('Im')(x2)) <> true) and traperror
         (is(x2,'real')) then
   5       if (not type(x2,'complexcons') or has(x2,'RootOf') or 
             `property/ProbablyNonZero`(x2) <> true) and traperror(is(
             x2,0)) then
   6           return 0
           else
   7           return x
           end if
       elif (not type(x2,'complexcons') or has(x2,'RootOf') or 
         `property/ProbablyNonZero`(('Re')(x2)) <> true) and 
         traperror(is(-I*x2,'real')) then
   8       return 0
       end if;
   9   return ('Re')(x)
end proc

Invoking your procedure with the command   wrong();   will only display the one plot that happens to be the return value, since the returned value will be displayed as output.

You could also do this,
   proc() print(plot(x)); printf("z"); print(plot(x)); end proc;
which displays both plots.  (It also returns NULL, since that is the result of the last statement which is a print statement.)

And you can vary it. You could have it forcibly print the first plot and return (and thus incidentally display) the second plot.

Here are some comments, and ways. (I'm sure there are others... possibly simpler).

I chose to use a Vector rather than a vector, and to map the `?[]` indexing command.

vector_of_lists_example_ac.mw

Enter a period (lower dot) for Matrix-Vector and Matrix-Matrix multplication, not a star (which displays as a center-dot in 2D Input).

Download trc_ac.mw

I found that using solve might depend on whether the changed equation was expanded, and upon the working precision (Digits).

You can also adjust Digits to see effect on residual (forward) error.

There are other ways to compute this (eg. using procedures which each raise working precision ie. Digits locally while keep fsolve's notion of accuracy (dependent on inbound Digits) coarser. I haven't done that. Similar effects can be had by treating it as an optimization problem (eg. by using DirectSearch, or setting it up that way).

Download no_conjugate_ac.mw

You can also use the command-completion facility, or the palettes, or the Ctl-Shift-G keyboard shortcut to easily construct compound names in 2D Input mode.

This also allows the names to appear in their nice typeset form as 2D Input, and not just as 2D Output.

See Help pages for command-completion and the entry palettes.

Download cmd_completion.mw

As Carl mentioned, you can also enter the compound names using its 1D equivalent notation (which -- as you can see above -- involves a name containing HTML-style entity, here). But for some kinds of typeset name you may not find that easy to guess, eg. names with a caret over them, etc.

In 2D Input mode, you can also use the keyboard acceleration Ctl-Shift-G to temporarily place the GUI into Greek-entry-mode. For your example, the same result for typeset 2D Input can also be had using the keystrokes,
   Ctl-Shift-G D x
There, the "D" makes it enter a Greek uppercase Delta. See the Help page.

In a previous Question you were shown in an Answer that the simplify command accepts the assume=[...] option.

That does not mean that option assume=[...] works for all commands. It does not.

The odetest command does not throw an error if you pass it some extra arguments.

If you want to construct your call (to utilize the assuming facility) from a precomputed list or collection of inputs then you can call using its prefix form:

sol:=y(x)^(1/2)=-1+2*exp(x):
ode:=diff(y(x),x)-2*y(x)=2*y(x)^(1/2):
`assuming`([odetest(sol,ode)], [x::real, x>0]);
                     0

Why are you trying to pass the plot function call around as if it were an object!? Do you have some special purpose where there really isn't a better programming methodology? (I can think of very few, and since you are new to Maple I suspect that your actual goal could be better done in another way altogether).

Having said that,

  eval('plot'(x, x = 0 .. a), a = 3);
  value(eval(%plot(x, x = 0 .. a), a = 3));
  ((e::uneval)->eval(e,a=3))( plot(x, x = 0 .. a) );

On this forum it is almost always better to inform us in detail of your actual motivating goal, rather than just inquiring about some barrier found during an attempt you devised for getting there.
 

You can customize and adjust this.

The idea is that you can write a convenient procedure to generate such plots in a reusable manner. And you could also augment the results futher.

Download plotting_fun.mw

Download unitconvert.mw

Since NULL is ephemeral when used in ways that you intend (eg. being passed around, or returned, in an expression sequence) then it isn't a very good choice. Don't choose something that can be problematic for one of your basic usage patterns.

Using {} is not terrible, but it will fall down for a computation where {} is also a possible natural result and where you need to distinguish between the two situations. In that case you'd have to utilize something else instead, which means that your methodologies could be inconsistent. Note that you didn't cite only computations where the result denoted possible solutions -- so {} might make sense to denote the empty set, but is not great to denote general cases where something "could not be computed".

How about using FAIL instead? Note that your two cited example circumstances were, "...it could be something that could not be computed inside foo, or some solution that could not be found". The common phrasing there is "could not be".

For the cases of computing possible solutions, would you want to be able to distinguish between the case of provably no solutions and the case where it happens to not succeed in finding any solution?

[edit] I don't think that solutions involving returning uneval-quoted NULL is great. You'd need to avoid using whatever it got assigned to in an analogous situation. Why introduce any need for extra care, if you don't have to?

Here is one way to deal with that, which consists of the step,

   subsindets(eq[4], float,u->`if`(frac(u)=0.0,trunc(u), u));

(There are more complicated ways, some of which deal with other things that you might encounter and want, such as stripping off trailing zeroes. Let us know...)

Download question_sunit_ac1.mw

Here is one way.

Let me know if you really prefer that multiple calls foo(ode,y,x) would produce the exact same result (in which case it could adjusted to be store and manage that, I think.)

Download genglobal.mw