web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Finance | Project Operations, Human Resources, ... / Exception handling - E...
Finance | Project Operations, Human Resources, ...
Answered

Exception handling - ErrorException was unhandled by user code

(0) ShareShare
ReportReport
Posted on by ist 805

Hi,

A strange exception handling behavior occurs in D3FO 10.0.7 PU31.

An example:

pastedimage1579172466866v1.png

appl.ttslevel() = 0 before ttsbegin;

During the debugging, the debugger stops on the last catch statement (outlined in red) and shows the exception dialog with the error (in red).

The exception should be caught in the last catch block but it shouldn't.

Any suggestions what's wrong?

Regards,

I have the same question (0)
  • Suggested answer
    Martin Dráb Profile Picture
    Martin Dráb 237,880 Most Valuable Professional on at

    No, I don't agree that it should be handled as CLRError. What you get is the normal X++ error, which is handled in the special way. You should be able to catch it by Exception::Error, not Exception::CLRError.

  • ist Profile Picture
    ist 805 on at

    Hi Martin,

    Thanks for your prompt.

    I didn't try to catch this kind of exception (Exception::Error) with catch (Exception::CLRError). I tried to catch Exception:Error with the last catch block where the exception type is not mentioned, so in the last catch block I would like to catch all kind of exceptions except these mentioned in the earliest catch blocs (Deadlock, UpdateConflict, DuplicateKeyException, and CLRError).  

    catch

    {

    ...

    }

    I tried also catch (Exception::Error) block but the result is the same (the debugger stops on the catch (Exception::Error) block and prompts with the same error message, which is very strange, because the exception is of the same type Exception::Error.

    I forgot to mention that it works in my dev environment (downloaded from D3FO VM images), but it doesn't work on the customer environments (DEV/TEST sandbox and PROD). The only difference is that my dev environment uses SQL Server but DEV/TEST/PROD use Azure SQL which shouldn't matter.

    Regards,

  • Sergei Minozhenko Profile Picture
    Sergei Minozhenko 23,093 on at

    Hi Jaret

    Does the build version of "downloaded from D3FO VM images" environment the same as "DEV/TEST sandbox and PROD" customer environments? And are you totally sure that there are no transactions on the upper level in customer environments?

    BR, Sergei

  • ist Profile Picture
    ist 805 on at

    Hi Sergei,

    The environment is the same as DEV/TEST sandbox and PROD. I have updated it to service update 10.0.7 PU31. Regarding the ttslevel, I checked it through debugging.

  • Suggested answer
    Martin Dráb Profile Picture
    Martin Dráb 237,880 Most Valuable Professional on at

    You said:

    I tried to catch Exception:Error with the last catch block where the exception type is not mentioned, so in the last catch block I would like to catch all kind of exceptions except these mentioned in the earliest catch blocs (Deadlock, UpdateConflict, DuplicateKeyException, and CLRError)

    And that's exactly what's happening - you get into the last catch block because the exception isn't either Deadlock, UpdateConflict, DuplicateKeyException or CLRError.

    And yes, catch(Exception::Error) behaves the same as the default catch, because both can catch Exception::Error. That's another proof that this exception isn't considered to be CLRError.

    I reproduced the error and although my situation isn't exactly the same as yours, my findings might be applicable. In my case, and the system works as it should, with a single exception. I get the "An exception of type 'Microsoft.Dynamics.Ax.Xpp.ErrorException' occurred in ExceptionHelper.dll but was not handled in user code" when I run the code in debugger. I believe that if you run code on DEV without debugging, you'll get the same behavior as in TEST and PROD.

  • Sergei Minozhenko Profile Picture
    Sergei Minozhenko 23,093 on at

    Hi Jaret

    Do you run your code in the same way in all environments? I get the same behaviour as you describe only if the whole try-catch statement is run in transaction.

    BR, Sergei

  • Martin Dráb Profile Picture
    Martin Dráb 237,880 Most Valuable Professional on at

    Sergei: Exceptions (of most types) can't be caught in transactions, therefore your catch clause is simply ignored.

  • Sergei Minozhenko Profile Picture
    Sergei Minozhenko 23,093 on at

    Hi Martin

    Yes, That's true. That why i'm suggesting to check if there are no transactions open before try .. catch statements.

    BR, Sergei

  • ist Profile Picture
    ist 805 on at

    Hi Martin and Sergei,

    The execution of my code starts in persitEntity method of a custom entity (when an external application posts a http request to Dynamics REST API).

    public void persistEntity(DataEntityRuntimeContext _entityCtx)
{
    super(_entityCtx);

    my code starts here instantiating a class and call class method.
    ...
}

    As described in my post at the beginning the method is as following:

    public void myMethod()	
{
	try
	{
		ttsbegin;
		...
		a validation check throws and exception -> throw error("error message");
		...
		ttscommit;
	}
	catch (Exception::Deadlock)
	{
	    if (retryNum < maxRetryAttempts)
        {
            retryNum  ;
            retry;
        }

		write inforlog error message to a log (in a table) because in this case there is no user interaction
	    throw Exception::Deadlock;
	}
	catch (Exception::UpdateConflict)
	{
		if (retryNum < maxRetryAttempts)
        {
            retryNum  ;
            retry;
        }
        
		write message to log
        throw Exception::UpdateConflictNotRecovered;		
	}
	catch (Exception::DuplicateKeyException)
	{
		if (retryNum < maxRetryAttempts)
        {
            retryNum  ;
            retry;
        }
        
		write message to log
		throw Exception::DuplicateKeyExceptionNotRecovered;
	}
	catch (Exception::CLRError)
	{
        var ex = ClrInterop::getLastException();
        if (ex != null)
        {
            ex = ex.get_InnerException();
            if (ex != null)
            {
                write message to log
            }
        }
	}
	catch
	{
		write message to log
	}
}

    Regards,

  • Verified answer
    Sergei Minozhenko Profile Picture
    Sergei Minozhenko 23,093 on at

    Hi Jaret

    I quickly checked ttsLevel in persistEntity method and it's equal to 1 in my case (there is no other code on the entity) and it explains try..catch behavior. I suggest you will double-check it as well.

    BR, Sergei

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

#1
Martin Dráb Profile Picture

Martin Dráb 584 Most Valuable Professional

#2
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 499 Super User 2025 Season 2

#3
Sohaib Cheema Profile Picture

Sohaib Cheema 254 User Group Leader

Last 30 days Overall leaderboard

Featured topics

End-of-life Announcement for Microsoft Dynamics GP

Product updates

Dynamics 365 release plans