Ahemmm,
your envisioned addition of Alias() as a parameter *IS* a change of Dougs implementation code, forcing you into maintainance every time Doug enhances his code. The idea is to handle Dougs object as black box with identical method signature, adding every now and future functionality to your personal subclass - as long as you persist your gathered data not in properties added to Dougs object but in an object certain not to name-clash, even if Doug adds Geolocation, humidity and temperature to his log, no additional maintainance is needed. With the added complexity of each approach you gain more freedom to re-use elsewhere, esp. with composed objects.

Adding parameters long term is a cul-de-sac: imagine you need to log user, machine name, CPU type, daylight saving setting as well ;-)


>Thank you for your detailed suggestion. I will look into it.
>
>But I will not change an error handling routine without good understanding and testing. Right now, I only want to add and store the alias() when an error occurred.
>
>>In the long run you are painting yourself into a corner with an approach based on adding to or modifying current parameter list.
>>
>>Speaking with no knowledge on Dougs class, I would bet small amounts that ANY subclass approach is better, from simply overwriting

>>function ini()
>>local llOk
>>llOk = dodefault()
>>this.Addobject("oDmitry", "empty")
>>return m.llOk
>>
>>function ErrorHandler(tnError, tcSys16, tnLineno)
>>= AddProperty(this.oDmitry, "cAlias", Alias())
>>return dodefault(m.tnError, m.tcSys16, m.tnLineno)

>>over a hook based approach

>>function ErrorHandler(tnError, tcSys16, tnLineno)
>>local luRet
>>this.Hook_ErrorHandler_Before(m.tnError, m.tcSys16, m.tnLineno)
>>luRet = dodefault(m.tnError, m.tcSys16, m.tnLineno)
>>this.Hook_ErrorHandler_Done(m.tnError, m.tcSys16, m.tnLineno)
>>return m.luRet

>>
>>to a construct where you set specific objects for each hook type or before/done

>>function ErrorHandler(tnError, tcSys16, tnLineno)
>>local luRet
>>this.oHookBefore.ErrorHandler(m.tnError, m.tcSys16, m.tnLineno)
>>luRet = dodefault(m.tnError, m.tcSys16, m.tnLineno)
>>this.oHookDone.ErrorHandler(m.tnError, m.tcSys16, m.tnLineno)
>>return m.luRet

>>in your specific .Init due to another settings object as factory specifying each class, allowing you more freedom in subclassing/specialising. Yes, last approach IS overenginered on purpose to give you an idea how far you might proceed for problems having much wider application range...
>>>In my application I use the error handler class developed by Doug Hennig many years ago. It is good and it serves/served the purpose. Over the years I add ed some code but for the most part it is the same.
>>>
>>>I want to add the logging of the ALIAS() at the time of the error. Right now the error class does not do it. So, here is what I see (and in initial test works) can be done:
>>>
>>>The error handler is instantiated with the following code:
>>>

>>>lcError = lcErrorObj + '.ErrorHandler(error(), sys(16), lineno())'
>>>

>>>
>>>So, I added the alias() to the above, as follows:
>>>

>>>lcError = lcErrorObj + '.ErrorHandler(error(), sys(16), lineno(), ALIAS())'
>>>

>>>
>>>Therefore, now the method ErrorHandler gets 4 parameters, the last of which is the alias()
>>>
>>>Anyone sees a potential problem with the above?
>>>
>>>TIA