Searching for previous occurrences of this I found this thread, that was fixed in 2015... but we are encountering something extremely similar using Llblgen Pro 5.7.3 cf: https://www.llblgen.com/tinyforum/Thread/23267

code snippets:

        public bool PenMove(byte siteId, DateTime date, int fromPenId, int toPenId, int lotId, int head,
            Guid transactionId)
        {
            try
            {
                using var adapter = new DataAccessAdapter(ConnectionString);
                return ActionProcedures.PenMove(siteId, fromPenId, toPenId, date, lotId, head, adapter) > 0;
            }
            catch (Exception e)
            {
                throw e.ToBusinessException();
            }

        }

If there is any sql exception within the stored procedure call, I see that exception in the generated code for ActionProcedures in my VS2022 debug IDE on the call.Call()

        public static int PenMove(System.Byte siteId, System.Int32 fromPenDgId, System.Int32 toPenDgId, System.DateTime date, System.Int32 lotDgId, System.Int32 intHeadToMove, IDataAccessCore dataAccessProvider)
        {
            using(var call = CreatePenMoveCall(dataAccessProvider, siteId, fromPenDgId, toPenDgId, date, lotDgId, intHeadToMove))
            {
                int toReturn = call.Call();
                return toReturn;
            }
        }

continuing the debug session after that exception is shown there, which should result in the same exception being caught by our try catch, we only get "The SqlParameter is already contained by another SqlParameterCollection"

The SqlParameter is already contained by another SqlParameterCollection. at System.Data.SqlClient.SqlParameterCollection.Validate(Int32 index, Object value) at System.Data.SqlClient.SqlParameterCollection.AddRange(Array values) at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.CreateStoredProcedureCallCommand(String storedProcedureToCall, DbParameter[] parameters) at SD.LLBLGen.Pro.ORMSupportClasses.DataAccessAdapterCore.CallActionStoredProcedure(String storedProcedureToCall, DbParameter[] parameters) at SD.LLBLGen.Pro.ORMSupportClasses.StoredProcedureCall.Call() at ITS.feedIT.Entities.DatabaseSpecific.ActionProcedures.PenMove(Byte siteId, Int32 fromPenDgId, Int32 toPenDgId, DateTime date, Int32 lotDgId, Int32 intHeadToMove, IDataAccessCore dataAccessProvider)

I have reproduced this with forcing an exception in my stored procedure, just to eliminate anything else going on there:

alter PROCEDURE [dbo].[PenMove]
    @siteId tinyint,
    @fromPenDgId int,
    @toPenDgId int,
    @date DateTime,
    @lotDgId int,
    @intHeadToMove int
AS
    declare @ret int
    select @ret = 1 / 0

oddly if I disable 'Just my code' in VS debug options, I then do get the correct exception propagated. These behaviors repeat every time I test this. I am using VS2022 17.4.3 (I'm avoiding 17.5 for now as there is a hot reload bug in that) Is this something in your code that is causing this in debug sessions ?

Thanks Simon

I'm not entirely sure what the root issue is here, is it that the vs debugger shows different exceptions or that you even get that exception which shouldn't occur? As you describe that when disabling a vs feature it works ok, I'm not entirely sure what it is in our code that might even trigger it... All exceptions caught are wrapped in our ORM... exceptions with extra data of the context in which the exceptions occurred.

You use a recovery strategy btw which might have caught the exception earlier?

Otis wrote:

I'm not entirely sure what the root issue is here, is it that the vs debugger shows different exceptions or that you even get that exception which shouldn't occur? As you describe that when disabling a vs feature it works ok, I'm not entirely sure what it is in our code that might even trigger it... All exceptions caught are wrapped in our ORM... exceptions with extra data of the context in which the exceptions occurred.

You use a recovery strategy btw which might have caught the exception earlier?

Thanks Otis for the fast reply. Thinking more on it since my message, it could plausibly be a race condition of some sort in your code. There were just a few debug sessions where I did receive the correct error, and I had a few breakpoints around at the time also - afffecting timing maybe. I could not forceably repeat that... and most of the time saw the initial debugger caught error not be caught by our try catch... with no code or ours executing in between. We are not using any RecoveryStrategies; and I thought that was the bug you fixed back in 2015. For sure this exception is being thrown and we are catching it.

I can't reproduce it.

I used the same SP, and the exception is always caught.

P.S. I'm using LLBLGen Pro v.5.9 & 5.10, but I don't see any changes related to this issue.

Walaa wrote:

I can't reproduce it.

I used the same SP, and the exception is always caught.

P.S. I'm using LLBLGen Pro v.5.9 & 5.10, but I don't see any changes related to this issue.

I think we will have to monitor this for now and see if we can collect any additional information for you. It seems at least we are not experiencing this on a release build. I did have one thought; that it could be something in one of our Llblgen Pro project settings/configuration that is causing this... but ultimately we are not able to catch the cause of this exception in any of our code... so how could it be?

Thanks again

Simon

I have honestly no idea. Viewing things in a debugger could trigger things tho, like a watch that reads a value on an object but reading that property might trigger an action that e.g. performs work that conflicts with what you're debugging. I suspect it's something to do with visual studio's debugger as switching off a setting there makes it go away you said.

Would be interesting if you could check JetBrains Rider as they use their own debugger (written from the ground up, not by MS).