flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Feature request about "err" directive.

Author
Thread Post new topic Reply to topic
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Hi, Tomasz.

Is it hard to make "err" directive to accept optional string that to be used instead of the message "Error: error directive encountered in the source file".

It will improve the diagnostic code in macros and the code.

Now I am using two different approaches in FreshLib, but any of them have some disadvantages. See the examples below:

Approach1:
Code:
          if ~defined __methods.\#name\#mname & defined ..here2
            display 2,'Not defined method: "', \`name,\`mname, '"!', 13, 10
            err
          else
.......    

The result is:

Image

Approach2:
Code:
          if ~defined __methods.\#name\#mname & defined ..here2
            Error! Not defined method: name mname !
          else
.........    

The result is:

Image

As you can see the second approach gives better result - at least the error message is only one and the text contains useful information on the problem.
But of course it is ugly hack...

The suggested syntax is:
Code:
          if ~defined __methods.\#name\#mname & defined ..here2
            err 'Not defined method "', \`name,\`mname, '"!'
          else
.......    


The expected result:
Quote:
Error: Not defined method "TCat.GetStr"!

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 22 May 2014, 17:54
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Code:
if something
  display "Method ABC not defined. I'm giving up"
  err ;WTF just happened?
end if    
Post 23 May 2014, 01:16
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
@revolution: please, detailed.
Post 23 May 2014, 04:43
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
I was thinking about the same feature for a long time. And therefore I was a bit frustrated when assert had been introduced making the unification of both error generation features impossible in a way, that supports custom error messages.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 May 2014, 11:56
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
One of the reasons why it was implemented this way, was that fasm always presents the complete line that has caused an error, therefore any message provided as an argument to ERR directive would usually end up being displayed twice. Also, when the ERR was implemented, it was intended to be, in a way, backwards compatible (almost like the UD2 opcode in the Intel architecture) - the older version of fasm react to it in a similar way, just the exact message differs ("illegal instruction" in old versions versus the dedicated message in the later ones).

The messages presented by fasm in the "error:" line form the closed set that equivalent to error codes returned by a function. In case of fasm.dll, each one of these messages has a dedicated code. The "user error" cased by the ERR directive is something like a general category of "other" - when something like that appears in any API, it is usual to provide additional detailed information in some other way (extended data structure, additional log, etc.). In case of fasm the most obvious way is to use the DISPLAY buffer, as revolution pointed out.
Post 23 May 2014, 14:34
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Tomasz Grysztar wrote:
One of the reasons why it was implemented this way, was that fasm always presents the complete line that has caused an error, therefore any message provided as an argument to ERR directive would usually end up being displayed twice.


But in the present implementation, the error message does not contains information about the causes of the error. Only about the fact that the compilation stopped. It is of course normal and expected, because the compiler can't know what caused the error. Only the user can. In this case, it is better to display something twice than not display it at all.

And one possible solution to this is to not display the row of the source, if the error is generated by "err" - in all cases, it does not carry any useful information, only the word "err".

Using of the "display" directive works, as I already demonstrated, but the solution ends with two error messages, one of them not useful at all.

One another solution is to simply ignore the whole text after the "err" directive and to make "err" directive to display very short message, like: "User error:" or simply "Error:". (Now an attempt to set string after err, leads to "extra characters on line"). But imho, it is dirty solution.

BTW, the "assert" directive makes the things even worse, because in this case, if more than one display directive is used in the source, the user displayed error message (by display directive) can be separated from the assert generated error message with many rows of other text, generated in the last pass.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 23 May 2014, 16:25
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
JohnFound wrote:
And one possible solution to this is to not display the row of the source, if the error is generated by "err" - in all cases, it does not carry any useful information, only the word "err".
It will show the comments following the err.
Code:
err ;This comment is also printed to the output    
.
Post 23 May 2014, 16:32
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
@revolution - It will not, because the displayed code line is restored from the preprocessed code, but there is no comments anymore.
Post 23 May 2014, 16:37
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
JohnFound wrote:
@revolution - It will not, because the displayed code line is restored from the preprocessed code, but there is no comments anymore.
Works for me:
Code:
flat assembler  version 1.71.20  (960953 kilobytes memory)
err.asm [1]:
err ;help
error: error directive encountered in source file.    
Post 23 May 2014, 16:39
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Strange. Not working in FASMW. Probably the console versions use another approach. But it is not so, important. More important is that in the comments you can't use preprocessor symbols that to be replaced with it's values - see the examples in my first post.
Post 23 May 2014, 16:49
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
JohnFound wrote:
Strange. Not working in FASMW.
My version of fasmw selects and highlights the line automatically.


Description:
Filesize: 6.18 KB
Viewed: 7291 Time(s)

ErrHelp.png


Post 23 May 2014, 16:51
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
Yes revolution, my as well. And Fresh IDE have the same behavior. But this fact does not solves the problem. And yes, I can see where the error is and can gather enough information in order to solve it. It is not a bug and as such does not need "fixing".
But it can be more user friendly and useful. It can improve the user experience. That is why I am asking about it as a "feature request".

Or you think "Error: error directive encountered in source file" is good and informative error message? It is actually captain Obvious replica, not an error message.
Post 23 May 2014, 17:08
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
therefore any message provided as an argument to ERR directive would usually end up being displayed twice

This one sounds convincing and I was thinking about adjusting the err functionality in a way that it ignores the remaining tokens on line, so that the "extra characters on line" is not displayed instead. But I find the JohnFound's suggestion to refrain from displaying the err line more sensible. I completely agree with him, that the err line in the error log does not carry any useful information.

Quote:
when the ERR was implemented, it was intended to be, in a way, backwards compatible

If I understand you correctly "backward compatibility" is here the possibility to use older versions of fasm in order to compile source codes for newer ones, right? I don't think, it makes any sense at all, because this kind of "backward compatibility" would be limited to very few fasm directives (any except err ?), and nearly any other feature of the newer versions would cause compilation failures. Why would someone at all write code for older fasm versions using a newer fasm? It's not even near the CPU story, when a company writes software using brand new Skylake's, but knows, that the majority of their users have SandyBridge's and some might still have NetBurst's to run the software.

The forward compatibility — the possibility to compile older source codes with newer fasm versions — is here much more important, but is broken anyway: e.g. it was possible to define a numeric constant with the name err before, and now this would fail to compile.

Quote:
The "user error" cased by the ERR directive is something like a general category of "other" - when something like that appears in any API, it is usual to provide additional detailed information in some other way

I'm missing the point, where the err directive was somehow unlucky to become this "some other way". A user-generated error is something somewhat unique and special to the closed set of errors anyway.


What bothers me in this story is the necessity to have multiple lines, when using the err or assert directive. I often need something like match ,arg { err "Argument value is missing" }, because an additional display makes me spread this line across five lines while obeying rules of my coding style. But I think it's too late to fix this now, because the incompatible syntax of the assert directive makes the fix incomplete. The feature is obviously not vital and display is again obviously a way to go. There's just one more unfortunate design decision. Fortunately, a quite harmless one. A humble opinion.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 May 2014, 19:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
If I understand you correctly "backward compatibility" is here the possibility to use older versions of fasm in order to compile source codes for newer ones, right? I don't think, it makes any sense at all, because this kind of "backward compatibility" would be limited to very few fasm directives (any except err ?), and nearly any other feature of the newer versions would cause compilation failures. Why would someone at all write code for older fasm versions using a newer fasm?
I have been using ERR in my macros for quite some time before this directive was actually implemented. Because any "illegal instruction" was enough for this purpose. And you could put any message in such line, because what follows the illegal instruction did not matter to assembler anyway.
So when I implemented the ERR as a special directive, it did not really change much in how these old macros worked, it just made it a bit more "formal", per request.

l_inc wrote:
I'm missing the point, where the err directive was somehow unlucky to become this "some other way". A user-generated error is something somewhat unique and special to the closed set of errors anyway.
A simple example: if there is an function that returns an error code (like in fasm.dll), then of course the error code cannot contain the additional message, as it is just a number. What I meant was that it is usual in API to have a code that means "other kind of error, see ... for more information", where "..." needs to be some additional data structure, or additional Get*-type API, etc.

l_inc wrote:
What bothers me in this story is the necessity to have multiple lines, when using the err or assert directive. I often need something like match ,arg { err "Argument value is missing" }, because an additional display makes me spread this line across five lines while obeying rules of my coding style.
I think that you in fact gave a very good example of how ERR can be used - as I wrote above, even with the old variant of relying on the "illegal instruction" behavior, one could put any message in the same line, and then the line ends up being presented as a whole. I still sometimes use such construction, though in official macros I combine it with DISPLAY.
Post 23 May 2014, 23:09
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
it did not really change much in how these old macros worked

Allowing an optional string argument would not change anything either.
Quote:
What I meant was that it is usual in API to have a code that means "other kind of error, see ... for more information, where "..." needs to be some additional data structure"

I understand that. And what I meant was that "..." could actually be an optional argument of the err directive. Or is there some point in making it harder to fill that "additional data structure"?
Quote:
I think that you in fact gave a very good example of how ERR can be used

But the output is not good enough. That is why I was originally thinking of an explicit ignoring of the remaining tokens on line, but ... (see the first paragraph of my previous post Smile)

But again, just to be clear. I'm not trying to convince you, that the subject is good to implement now. Mainly because I think, that err and assert should have a uniform syntax, and it's now too late for assert.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 May 2014, 23:32
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.