@emendes You could somewhat reasonably extended your catch to , say,

   catch "time expired","does not exist","invalid input","at offset":

You could also insert another catch clause (a try..catch can have several, which are checked in succession). It is sometimes useful to put in, as a final catch clause, a plain,

   catch:

to trap any remaining errors.

Then you may deal with that as you see fit. You could print something or take some suitable computational action, then optionally rethrow an equivalent error message using the error statement.

See also the use of the StringTools:-FormatMessage command, and lastexception, in an Example on the ?error Help page. This is sometimes useful, for re-throwing a message, turning an error into a warning, or what have you.

What I meant about flags is that in some complicated situations the preliminary actions done within the try clause (prior to an error) might change the state of some variables, etc. You might have a situation in which you need to reset certain things in a finally clause, and so it can help to record the initial status or successes at earlier stages.

Breaking up a try..end try with an overly involved try clause into smaller steps can sometimes help, if it becomes unwieldy.

@Carl Love Something like this?

Download genglobal_ac3.mw

@nm Ok, you did not state in the original question that you wanted repeat calls to utilize the same dummy name. But as I mentioned, it could be accomodated.

Do you want different ode problems involving the same third argument to utilize the same new name? I'll guess that is so, too.

Download genglobal_ac2.mw

It's always better to describe as much about your requirements as you can up front.

@Ali Hassani Please keep this discussion centralized, instead of spawning off an unconnected new Question thread.

@nm It's just not clear whether the call to currentdir and the reassignment to libname occur within the body of the test procedure, or not. Carl's Answer is supposing that they do not. It's still not clear.

@Carl Love It is not clear from the code fragments posted to date in the Comments that the two statements (identified by the OP as being problematic) are outside the definition of the procedure assigned to module local dsolver_test:-test .

The Comment was posted with this,

dsolver_test := module()
option package;
....
export test:=proc()
local main_dir := "C:/tmp/current_version";
...

   #these two lines were the cause
   currentdir(main_dir):   
   :-libname := main_dir, :-libname;

.....
     foo() #foo is just another local proc in this module
.....
end proc;

Those two lines appear before the end proc that appears to close the definition of the procedure assigned to test. So they appear to be part of the procedure body, in which case your explanation does not apply to this case.

However, since the code fragments also lack an end module it is possible that end proc is a typographical error and is intended to represent an end module, and that the actual end proc might be (as yet unshown and) before the two lines in question. In that case your explanation could be germane.

I find the provided code fragment to be a muddle. It's a pity that the OP could not take the time to provide actual full code to reproduce the issue. It seems to me that the OP has merely changed coding methodology without doggedly pursuing the cause and understanding of the original problem.

@Rouben Rostamian  FYI, the nicer form of the integration (involving the GAMMA call rather than EllipticK and EllipticE calls and the imaginary unit) is obtained directly from the nested int call in Maple 2019.2 and earlier (back to at least 16.02).

It can also be had directly in Maple 2020 with the meijerg and meijergspecial methods, eg.

f:=x->sqrt(x^(2/3)-x^2):
int(int(x,y=-f(x)..f(x)),x=0..1,method=meijerg);

                          2  1/2
                GAMMA(3/4)  2
            2/5 ----------------
                       1/2
                     Pi

There are also a few simplification weaknesses lying about, eg. converting EllipticE(I)
to GAMMA_related, etc.

I shall submit a bug report.

Provide the example that reproduces the problem with an .mla archive, if you want us to figure out what's going wrong in it.

By this I mean code that defines the module, and the code that stores it in a .mla Library Archive, and the example that subsequently does not run as expected.

@janhardo Persevering here should work. I do it this way often, and it's pretty straightforward.

@nm If you are seeking a way to get a location automatically added to `libname` (without using an initialization file) then here is how:

Place the .mla in a directory whose name can be formed as follows,

  cat(kernelopts(':-homedir'),"/maple/toolbox/foobar/lib");

The kernel should add that to libname after any restart. The GUI should also pick up that location for .hdb and .help archives, following  complete closure and relaunch of GUI.

A version specific variant is as follows, eg.

   cat(kernelopts(':-homedir'),"/maple/toolbox/2020/foobar/lib");

You can use multiple such locations, named as other than just "foobar".

This mechanism dates back to the introduction of the Global Optimization Toolbox, the first toolbox.

[edited] This mechanism works on Linux, OSX, and MS-Windows. As mentioned, there is are both version-specific and version-agnostic variants. IIRC it is also the scheme now used by the "package" management system.

note. I am camping on Lake Huron and typing this in by cellphone. Please check for typos and errors.

@nm I know nothing about what you're trying to accomplish with all this, or what your ulterior purpose might be, since you haven't stated it.

I look at kernelopts(':-mapledir') if I want to programmatically access the directory in which my Maple is installed. Similarly I use kernelopts(':-homedir') to get at the OS's notion of home directory.

@PhD_Wallyson The name params is not assigned to anything, which is the direct cause of the error (as should be understandable by reading the error message).

Is params supposed to be a sequence of equations, say denoting values for L1,L2,L3?

@eslamelidy Here is one way to construct the plots for various values of beta. You can see that your choices of beta don't seem to make much difference.

x_e_-.008_ac.mw

@eslamelidy I'll look at that. Don't repost it as a duplicate Question, please.

@vv That produces an incorrect result in Maple 2015, since IntegrationTools:-Expand pulls q altogether out of the integrals.