Community discussions

MikroTik App
 
freakneck
just joined
Topic Author
Posts: 11
Joined: Thu Feb 05, 2015 10:32 pm

Error handling?

Fri Oct 07, 2016 11:35 pm

I've got system out there at a couple different f/w levels.

At some point in the f/w development cycle, MT added error handling to scripting.

Also, at some point, under /system ntp client the mode setting had been removed. When it was initially removed, mode would still show up as a possible choice if you pressed TAB after the SET keyword.

Anyway.....

In an attempt to create a single script to support f/w's that did and didn't have that setting any longer, I thought error handling would be a good choice here.

So I came up with this....

:do {/system ntp client set mode=unicast
} err={};


...but it still throws an error!!!! I know that the mode setting was removed, and that it should error out there, if I wasn't using an error handler!!!

What gives?
 
CsXen
Frequent Visitor
Frequent Visitor
Posts: 94
Joined: Wed Sep 10, 2014 8:31 pm
Location: Budapest - Hungary

Re: Error handling?

Wed Dec 14, 2016 2:32 pm

Hi.
I tried it for hours... but i concluded, that error handling works just for internal commands (which starts with : like ":resolv"),
and not works for path commands (which starts with /like "/tool dns-update..."

In the first case you can catch an error with on-error={} , in the second, command aborts the script with it's own error.

So we must send a feature request to Mikrotik... if we want to catch error in all commands. :)

Best regards: CsXen
 
CTSsean
Frequent Visitor
Frequent Visitor
Posts: 61
Joined: Fri Sep 15, 2017 12:56 pm

Re: Error handling?

Tue May 15, 2018 4:27 pm

Going to resurrect this as I found this during my runtime error handling testing.

The syntax format has to be very specific to process the error handling properly.

Example:
:do {/interface bridge add name=loopback; } on-error={:put "loopback exists"}
So its

:do {whatever command you want to run; } on-error={whatever command you want to run if it errors}

Be mindful of the curlys and semi colons.

I recommend when trying to do error handling per command, you keep the error handling on the same line.
 
damianivereigh
just joined
Posts: 15
Joined: Sun May 22, 2016 1:06 am

Re: Error handling?

Sat Mar 09, 2019 2:06 pm

I think I have to the solution to this issue. If you put the code that may have a syntax error into :parse, then you can execute that inside a do { } on-error={} and it will catch syntax errors too.

So to use your example...

:global mycode [:parse "/system ntp client set mode=unicast" ]
:do { $mycode } on-error={}
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Error handling?

Thu Sep 09, 2021 5:36 pm

Start to coding correctly and you do not have problems:

# wrong coding
:do {/interface bridge add name=loopback; } on-error={:put "loopback exists"}
# translating: create loopback, if you got an error because already exist, ignore it
# on short: create it, hoping not already exist

# right coding
/interface bridge
:if ([:len [:find where name="loopback"]] = 0) do={add name=loopback}
# translating: if the result of the count of interface named loopback are zero, create the interface
# on short: if not exist, create it

and about NTP, simply check first the RouterOS version...

and use this example for know if the NPT package are installed and enabled or not:

(example for Jotne for Splunk)
:local ntpstatus ""
:if ([:len [/system package find where !disabled and name=ntp]] > 0) do={
    :set ntpstatus [/system ntp client get status]
} else={
    :if ([:typeof [/system ntp client get last-update-from]] = "nil") do={
        :set ntpstatus "using-local-clock"
    } else={
        :set ntpstatus "synchronized"
    }
}
:log info message="script=ntp status=$ntpstatus"

Who is online

Users browsing this forum: No registered users and 20 guests