Enums for @extended values?

[Danp2]

Feature request

Some existing WD UDFs set @extended to indicate more details on the type of error that occurred. They currently use "magic" numbers instead of a constant.

Describe the solution you'd like

Add a Global Enum to define these values

Describe alternatives you've considered

Do nothing

Additional context

None

[mlipok]

Can we use @scriptlinenumber ?

[Danp2]

You mean instead of Enums? I don't know if that's a good idea. This wouldn't work with compiled scripts, right?

[mlipok]

Yeah.

[mlipok]

Today I came to the issue: _WD_UpdateDriver ==> Browser or feature not supported (19 / 21) : DriverCurrent = : DriverLatest =

It was really easy to find:

$iExt = 21 ; $iExt from 21 to 29 are related to _WD_GetBrowserPath()

So generally as to question: Enums for @extended values? Answer is: No

So I vote to close this issue.

[mlipok]

So generally as to question: Enums for @Extended values? Answer is: No

So I vote to close this issue.

@Danp2 your decision or comment?

[Danp2]

My concern still exists regarding the use of "magic" numbers. Your coding revisions have proved this exact point by changing the value of $iExt over time in some functions.

What happens when the calling script starts checking for @extended = 21 (from your example above), and then you internally change 21 to some other arbitrary number?

[Danp2]

@mlipok Any thoughts on my last comment above?

[mlipok]

A warrning should be added to the top of UDF When $iExt is set to a raw number do not treat them as static value, because they may change in the future. This is only a way of finding point where or why the script exits (returns from function). Because of this reason you can store this value or manually checking in investigation, but do not rely on them in your script runtime.

[Danp2]

Not crazy about that idea. Will need to think about it.

[mlipok]

Will need to think about it.

It's not a problem, he's been waiting for almost two months, so he'll wait for the next one.

[mlipok]

What you think about this kind of simultaneous use: ($iExt + $sMessage usage)

[Danp2]

What you think about this kind of simultaneous use

You may want to elaborate as to what you mean by "simultaneous use".

[mlipok]

to use $sMessage together with $iExt. For example _WD_GetBrowserPath() sets $iExt but is not using $sMessages.

Mabye we should review $iExt usage and add for each of them also $sMessages ?

[Danp2]

These parameters ($iExt and $sMessages) are optional, and they can be supplied independently. You can review existing functions and add $sMessages if you desire, but it isn't required.

[mlipok]

I like the current implementation. I think that from about a year there was no any issue with this. so IMHO we can close this issue.