about the assert - (Moved)

[636C65616E]

Hey there,

Long time since the last time i came around hehe, had to work on some project using AutoIt recently ... so here i am again 

Here's something i was a bit confused about since a long time : why not adding a simple assert function to the langage ? (many langages already include this as a native feature ).

cheers

nb: i checked quickly if there was already a topic about that, without success (so soz for the dup topic if it is the case)

[argumentum]

36 minutes ago, 636C65616E said:

why not adding a simple assert function to the langage ?

But how would you implement it ?. How do you envision such in a script ?. Where is the need ?.
Post a mock script where the function would be used just to see how/where it would be used, that an existing technique just doesn't cut it.  

[Jos]

Moved to the appropriate forum.

Moderation Team

[636C65616E]

@Jos ty for moving  

A simple use case : crash the program with appropriate exit code and flush to stderr some error handling msg

I usually use an udf to do it in all my projects, so i mainly ask because it is just about redundancy ^^ (i mean you have this kind of native feature in nearly all scripting langages i can think about).

I was wondering if it would be a good idea, as it is something so commoly used and "basic" in some sense when in dev mod (ofc you will probably handle errors in an other way when u go to deployment), so asking just for the sake of asking ( i'm an innocent and naive beeing (: ).

Edited January 10 by 636C65616E

[argumentum]

https://www.autoitscript.com/autoit3/docs/appendix/Exitcodes.htm ?

Opt("SetExitCode", 1)
$CmdLine[100] = "hmmm"

 

Edited January 10 by argumentum
added the code

[636C65616E]

will be a part of ... (as you crash the programm)

you can kinda argue the same for any other langage implementing it (you can exit, you can handle error, even exception, etc) but the use of assert itself is not questionnable.

The purpose of an assert is not to handle error nor return exit code, but to keep track (when you dev) of assertions (stuff that must be true), otherwise the error causing the malfunction is mainly a problem relative to you not understanding what's really going on, or to malfunction in some cases.

for instance:

a square have 4 sides of equal length
imagine you code a programm handling some quadrilateral and you *except* it to be a square, then it *must* (this is an assertion) have 4 sides of equal length, if not the problem is not about handling an error : it is about the purpose of your program itself and how it is used in the end or where this given quadrilateral come from

assertion != error handling

assertions should disappear when you release/deploy your programm

it is a fast forward way to code when you expect the behavior of your programm, in some sense it follows some kind of TDD pattern : run => fail => correct => continue

when handling distances you must admit those quantities are positives

a segfault could be a 'legit' ("inverse")assertion (you must have allocated and have access to the memory)

when dividing you must assert the divisor is non null

i hope i was clear, ofc those 2 last example are a bit edgies (some langage handle them, some dont) the use of assert is more "conceptual" than "practical"

it can also fall, in some case, on assuming the succes of uncontrollable events (as for memory allocation : the OS not beeing able to allocate the memory, most of the time you will have no control on the 'why' it happens if it is done correctly, and you should probably assert the OS will always be able to allocate)

Edited January 10 by 636C65616E

[argumentum]

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_Change2CUI=y
#AutoIt3Wrapper_Run_Au3Stripper=y
#Au3Stripper_Parameters=/mo
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
#cs ----------------------------------------------------------------------------

 AutoIt Version: 3.3.16.1

#ce ----------------------------------------------------------------------------

; Script Start - Add your code below here
Opt("SetExitCode", 1)
If $CmdLine[0] = 0 Then ; https://www.autoitscript.com/autoit3/docs/appendix/Exitcodes.htm
    ; for CUI compile, adding "/ErrorStdOut" will write out the line number and error description"
    ; "(8) : ==> Array variable has incorrect number of subscripts or subscript dimension range exceeded.:"
    MsgBox(262144, "ExitCode:", "0x" & Hex(RunWait('"' & @AutoItExe & '" /ErrorStdOut ' & (@Compiled ? '' : '"' & @ScriptFullPath & '" ') & '/crash')), 8)
ElseIf $CmdLine[1] = "/crash" Then
    $CmdLine[100] = "hmmm"
EndIf

Code I can understand. The above shows my point of view.
In AutoIt you have @error or whatnot. Try{ .. } ... would not work.
Write in code what you meant by "a square have 4 sides ..." and maybe I** can see the use of such in AutoIt.

** I and anyone else trying to make sense of its use in this language, as what you propose is very fundamental to a language architecture.

Edit: I better the code for those looking for an example of Opt("SetExitCode", 1)

Edited January 10 by argumentum
better code

[636C65616E]

i edited my last message, but a simple proof of concept : (i often use something quite similar in my projects)

func assert($check, $msg='', $line=@SCRIPTLINENUMBER)
    if (not $check) then
        ConsoleWriteError('[assertion failed @' & $line & '] ' & $smg)
        Exit
    endif
endfunc

func compare_ages($age1,$age2)
    assert($age1 > 0)
    assert($age2 > 0)
    ; do stuff
endfunc

 

Edited January 10 by 636C65616E

[argumentum]

21 minutes ago, 636C65616E said:

on assuming the succes of uncontrollable events (as for memory allocation

in https://www.autoitscript.com/forum/files/file/476-setmicforplayback/ there's code I used to troubleshoot.
I believe that memory allocation within AutoIt can be foreseen and if the OS is out of resources then that's that. Tho you can make your script reentrant, if you are careful with what you're doing.

 

[argumentum]

11 minutes ago, 636C65616E said:

But a simple proof of concept

func assert($check = Default, $msg='', $line=@SCRIPTLINENUMBER)
    if $check = Default then
        ConsoleWriteError('[assertion failed @' & $line & '] ' & $smg)
        Exit
    endif
    Return $check
endfunc

 

Edited January 10 by argumentum
better code

[636C65616E]

dont get why you quoted that (edit: there's no default value to the assertion : the statement must be clear and understood)

you can maybe see that as (this is not really the case but for the sake of the metaphore) your anchors points when doing rock climbing : it's a "check point" you assume everything is OK at this step of your climb, you continue and maybe you will fall, the assertion will give you hint why (because those must be true).

maybe this is not the best analogy haha

Edited January 10 by 636C65616E

[argumentum]

lol, I do. I get it. But this is Sparta ! But this is AutoIt.
One has to code each function taking in consideration every possible mishap. As if coding a UDF but for your own self. That is how I ended up coding after falling from a long way up while rock climbing, repeatedly 

[636C65616E]

Also, for instance, when compiling C code : switching from debug to release mode will turn off asserts (completly removing them from the bin, not even compiling them).

I mean this is a so common stuff : stands for the reason why i was asking in first instance

Edited January 10 by 636C65616E

[Nine]

Well the function already exists : look here

[636C65616E]

hoo, well, yeah in Debug.au3 (forgot that, but true ^^)

I was asking if it could fit as a keyword (a native feature).

[Nine]

I would think if Devs decided to put the function in an UDF, it is there to stay 

[636C65616E]

okok, do we have an option when building to remove them btw ? (now i remember looking for that in the past).

But you're probably true (: Jos could have ended this thread way faster haha (activating the trap card)

[Nine]

Not precisely, but the good thing, when you omit the #include all debug statements will show an error.  You can easily jump from one error to the other and remove all the concerned lines.

[636C65616E]

ok, because I remember writting some kind of parser to remove all my assert before building (this is why as a keyword it should make sense).

[Nine]

For the fun of it :

#include-once
#include <Constants.au3>
#include <Array.au3>

RemoveAssert()

Func RemoveAssert()
  Local $hScite = WinGetHandle("[CLASS:SciTEWindow]")
  If Not $hScite Then Exit MsgBox($MB_OK, "Error", "Scite must be started")
  Local $hEdit = ControlGetHandle($hScite, "", "Scintilla1")
  Local $sText = ControlGetText($hScite, "", $hEdit)
  Local $aLine = StringSplit($sText, @CRLF, $STR_ENTIRESPLIT + $STR_NOCOUNT)
  $aDel = _ArrayFindAll($aLine, "(?im)^_Assert\h*\(|[\W]_Assert\h*\(", 0, 0, 0, 3)
  If Not IsArray($aDel) Then Exit MsgBox($MB_OK, "Error", "No _Assert found")
  ;_ArrayDisplay($aDel)
  _ArrayInsert($aDel, 0, UBound($aDel))
  _ArrayDelete($aLine, $aDel)
  ClipPut(_ArrayToString($aLine, @CRLF))
  ControlSend($hScite, "", $hEdit, "^a^v")
  MsgBox($MB_OK, "Info", $aDel[0] & " _Assert lines was removed")
  Exit
EndFunc

Make it a file, #include this file at the beginning of your script, press F5, voilà...

Edited January 10 by Nine