Proper Function Exception Handling (help)

I am converting a fair chunk of code from a classic customization into functions.

I am using the rest helper website to help in unit testing my functions for proper handling of error conditions.

Although I have try/catch blocks around my code I often get the infamous error:
Sorry! Something went wrong. Please contact your system administrator. Correlation Id: 819aa8a8-ab16-4c6a-a006-43f29ea194d5
(this show up as the response from the rest call)

When I catch an exception I simply put some debug output in my function “output” parameter so I can see the exception message in my response

If I call my function via the rest helper and I’m testing the happy path, the response looks fine,

I don’t get why my catch block is not catching the error and allowing me to see it

A lot of these messages are called by sending incorrect data to the json parser.

help me understand, do you mean the parsing of the request parameters ?
that feels odd cuz I have some very simple request bodies, like a single string or integer for example

yes

I didn’t say it was the only reason.

Passing it back incorrectly will screw it up too.

All I’m saying is, most of the times, it’s because I’ve done something dumb.

here is an example of a test function I created to test calling a BO method

// Function zzTestBoMethodCall

try
{

//  initialize to false
oSuccess = false;
 
string nl = Environment.NewLine;
 
StringBuilder statusBuilder = new StringBuilder("Function zzTestBoMethodCall" + nl);

Ice.Common.BusinessObjectMessageType m = Ice.Common.BusinessObjectMessageType.Warning;
Ice.Bpm.InfoMessageDisplayMode d = Ice.Bpm.InfoMessageDisplayMode.Individual;

    this.CallService<Erp.Contracts.JobEntrySvcContract>(jobEntrySvc =>
    {
        string jobNum = iJobNum;
    
        var jobEntryTS = new Erp.Tablesets.JobEntryTableset();
        
        jobEntryTS = jobEntrySvc.GetByID(jobNum);
        
        statusBuilder.Append("Retrieved job " + jobNum + nl);
        
        // try to modify a field
        var jobRow = jobEntryTS.JobHead.FirstOrDefault();
        
        string jobType = jobRow.JobType.ToString();
        string partNum = jobEntryTS.JobHead[0].PartNum;
        
        statusBuilder.Append("JobType / PartNum " + jobType + " / " + partNum + nl);
        
        jobEntryTS.JobHead[0].PartNum = "CDIGV";
        jobEntryTS.JobHead[0].RowMod = "U";
        
        jobEntrySvc.ChangeJobHeadPartNum(ref jobEntryTS);
        jobEntrySvc.Update(ref jobEntryTS);
        
        statusBuilder.Append("ChangeJobHeadPartNum called" + nl);

        statusBuilder.Append("zzTestBoMethodCall Finished" + nl);
        
        oStatus = statusBuilder.ToString();
        oSuccess = false;
    });
}
    
catch (Exception ex)
{
    oStatus = "caught exception";
        
    // Ice.Diagnostics.Log.WriteEntry("Catch: " + ex.Message);
    // Ice.Diagnostics.Log.WriteEntry("Catch: " + ex.InnerException.Message);

    // statusBuilder.Append("Exception encountered" + ex.Message + nl);
    // statusBuilder.Append("Inner Exception" + ex.InnerException.Message + nl);
    
    // oStatus = statusBuilder.ToString();
    // oSuccess = false;
}

the function does not throw an exception if I remove the jobEntrySvc.Update() call,
so it’s definitely past the json request parsing.

I’m not really as interested in just fixing by removing that call, I’m more interested in if it’s possible to catch such errors generally

I Love U Ily GIF by i-love-you

It is. I’m not sure quite how to explain my experience.

That code you have, did you test it exactly, or were these in there?

ex.InnerException.Message

InnerException can be null, you must check for it. Otherwise you error… in your exception handler.

ah, dang, overlooked that, that may be the culprit, will give it a try, I’ve been busying making several functions and following a pattern I have, so it may be causing much of the issue, will reply when I check it

I hope that’s the only thing, if not, we’ll be here.

I spent a day chasing that one down one time. Learned the hard way :slight_smile:

yeah, that didn’t help, I commented out all the lines in the catch block, still got the correlation id error, again removing the update lets my function complete (no error) but I’m encountering this in other functions also and my theory is that try catch blocks should work regardless

That code worked for me and caught the exception. Unchanged.

Are you sure you are using the correct API Key?

Are you sure your Library is published?

so by doing a “Ice.Diagnostics.Log.WriteEntry(” and hooking my function into the Company data directive I do get the server side exception and inner exception details…

I’d rather be able to test via the rest helper but I guess for now I can live with this to try to figure out the errors one by one

what?

Anyway, it works here unchanged. In swagger. Have you tried logging out of swagger and back in?

Do you have transaction scope checked on your function?

I did have transaction checked and unchecked it because of the exception thrown when executing thru the data directive. That did help

So now it is executing cleaner, still getting the exception when executing in REST helper but at least it’s catching it and telling me “Update not allowed, Job Closed” in the exception.Message

so at least that’s a hint

1 Like

There’s a thread on it somewhere here I remembered. I was wondering, because I was pretty
sure that BO you’re calling uses one internally.

You don’t normally need the transaction scope.

Yeah, I think I turned that on because of my frustrations, I remember seeing the posts about that

been there