Error handling in dxl

Hello,

I am developing a dxl script where i have to handle Error in the script.

I have to catch the error and then write them into a xml script.

I am using : 

noError 

<Code>

if(!null lastError)

{

string error=lastError

}

<write error into an xml>

Here I am catching last error which occurred into the dxl, But according to client's requirement they want to catch the first error write it into an xml and then stop the entire dxl execution for the rest of the code.

I am not able to catch first error is there any method like firstError in dxl? 

Or any small script to run to catch first error 

 

Your help will be appreciated :)

 

Thanks,

 

 


Tusharz - Tue Dec 26 09:07:45 EST 2017

Re: Error handling in dxl
EHcnck - Tue Dec 26 09:31:21 EST 2017

you would have to use noError around each executable statement.

Re: Error handling in dxl
Tusharz - Wed Dec 27 04:50:17 EST 2017

EHcnck - Tue Dec 26 09:31:21 EST 2017

you would have to use noError around each executable statement.

thanks

Yes i am doing exactly that but it increases the code unnecessarily

i was just wondering if there were some other way around it.

 

Re: Error handling in dxl
MaltePlath - Wed Jan 17 08:14:32 EST 2018

I think there is a misunderstanding here: lastError indeed reports the last error that occurred:

noError()
function_with_error()
lastError()

noError() // forgets the previous error
another_failing_function()
lastError() // will report the error from another_failing_function

 

But error handling with noError/lastError handles errors that would terminate your script. Therefore:

noError()

// a whole lot of code.

// At some point an error occurs,
// and the execution jumps to lastError

// This part of the code is not executed 

lastError()

So, in fact, the "last error" is the first error!

If you do not need to recover from errors within the run of the script, you can use just one noError/lastError bracket around all the script.

Disclaimer: This may not be true if you are doing fancy stuff with eval(), callbacks (GUI), asynchronous HTTP requests - anything approaching asynchronous processing may invalidate what I said above because some code may still be pending execution regardless.