1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

ISO Plugin: Yes, it's wonderful, but it could be yet more wonderful...

Discussion in 'Plugins' started by mathewsdw, Jun 15, 2012.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Charles, It's been my habit over all my years of writing code to do complete error checking and reporting of found errors in terms that a human being who is not a programmer can understand, and I'm actually somewhat obsessive about doing that. That means that in code that I write a message such as ISO8601 plugin: D:\ShowTimeNonFailure.btm [6] Invalid time "abc" is not acceptable to me; I don't want to see where the message is coming from ("ISO8601 plugin:"), the name of the .btm file where the error occurred and the line number on which the error occurred (no further comment needed), and I even want to supply the exact error text myself so that it is worded in terms that the user can fully understand (specifically the ultimate source of the data that is in error). Well as far as I can tell the ISO plugin fails on all three counts. Specifically, the .btm file "ShowInvalidTimeProcessingResults.btm":
    Code:
    @Echo Off
    SetLocal
    Set BadTime=abc
    @Echo Bad Time: %BadTime
    On Error MsgBox /M /S OK Error!!!
    @Echo >&NUL: %@TimePlus[%BadTime,0]
    EndLocal
    Quit 0
    
    and the results of executing it:
    Code:
    [D:\]ShowInvalidTimeProcessingResults
    Bad Time: abc
    ISO8601 plugin: D:\ShowInvalidTimeProcessingResults.btm [6]  Invalid time "abc"
    
    Note that the "On Error" didn't "catch" the error, the error message was printed despite the redirection of the error stream to null, and, of course, that's really not the message I want the user to see in the first place.

    So, two possible ways to fix this:

    1. Let the plugin "report" errors in the same manner as TCC does itself in batch files, i.e., the actual error message being redirectable to NUL: or any place of the user's choosing and the error being catchable by an "On Error" statement.

    2. If that's not really practical because of the basic underlying architecture of the TCC "plugin" capability (I have no idea whether or not that is the case), alternatively a function could be supplied that can validate times (a similar function for dates would also be useful) either just generically verifying times in either AM/PM format or in 24 hour format, or maybe a parameter that can be used to specify which format is wanted by the user, or even a result of the function that indicates which particular format the time was in if the time was, in fact, valid.

    For the short term I'll write my own code to do this, but it would be really nice if the plugin did this for me (and other users).

    BTW, just so it doesn't get "lost in the crowd", again the plugin is really wonderful, just not quite perfect yet.

    - Dan
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Well, "perfection is not a human option", though software can asymptotically approach it. Furthermore, for software used by many perfection is in the eye of the beholder - my requirements (or desires) may be [actually, definitely are] different from those of anyone else.

    Regardless, I do agree with Dan that it should be possible to intercept all error messages prior to display to the ultimate user. I do not know why neither "on error" nor redirection of STDERR captured the message without actually displaying it. I am curious...

    Furthermore, it is very useful to know WHY a parameter is invalid. I do support the idea of a function or set of functions which do nothing more than validate strings to be used for a particular category of parameters (date, time, date-and-time, etc.) in other functions, and if necessary report why invalid. The value of such a function could be zero (0) for valid input, and a list of non-zero values for invalid input, the list - of course - dependent on what the input should be. Undoubtedly internally you already have the basic elements of such a function - to generate the very message Dan objects to. So this request is essentially not much more than asking that your internal function would have an external interface. So much more code... for you, and less for our own work.
     
  3. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,311
    Likes Received:
    39
    That's exactly what I want to see! The source, the location, and the nature of the error.... And of course it mirrors the way TCC itself reports errors, not by coincidence.

    Regarding redirection of the error message from the function: We get this question from time to time, not always about plugins. It's not a plugin issue; you can see the same thing with internal functions:

    Code:
    echo %@diskfree[] >& nul:
    
    What's going on is that the functions -- all variables, in fact -- are expanded before the redirection takes place. Otherwise, you couldn't use functions (variables, etc.) in the filename! There is a simple workaround: use parentheses to force the redirection before the command is expanded:

    Code:
    ( echo %@diskfree[] ) >& nul:
    
    As for ON ERROR, it doesn't trap custom error messages, i.e. negative return codes. I think it would be possible for it to work that way, but that's really for Rex to decide. (Whether it's possible, and whether it's desirable!) If you really want this, you'll have to submit a feature request to him. I'll be interested to hear what he has to say about the notion.

    We already have @ISDATE to validate dates. (Say that ten times fast.) An @ISTIME function wouldn't be hard to add. But how should it work? Should it just return 1 for "good" and 0 for "bad", as @ISDATE does, or should it returns info on the time supplied -- 12-hour vs. 24-hour, were seconds specified, were milliseconds specified...?
     
  4. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    No, @ISTIME should return 1 or 0, as @ISDATE does. If you want to indicate what components were specified, two new functions should be created:
    @DATEPARTS and @TIMEPARTS which would return a bit-encoded number, each bit indicating that a component was specified. @DATEPARTS would have bits for year, month, and date; @TIMEPARTS would have bits for hour, minute, second, millisecond, and am/pm indicator (and maybe offset from UTC). (And that would allow detection of a partial date, like 31-Dec.)
     
  5. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,311
    Likes Received:
    39
    You read my mind, Dave. I have already implemented @ISTIME and @TIMEPARTS, both exactly as you say! (Both are trivial; most of the work is just documentation....)

    I don't think @DATEPARTS will happen, though. My ParseDate() routine doesn't return that info, and there are just too many ways of specifying a date: as year-month-day, as a julian, year-day, year-week-day, as an offset from today's date....
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,311
    Likes Received:
    39
    I have uploaded a new build here:
    http://www.unm.edu/~cdye/plugins/index.html

    I've done some automated testing and convinced myself that the new time functions do work as advertised, so the plugin is no longer beta.
     
  7. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Thank you very, very, much Charles, and I had kind of suspected that that would be the case for catching errors created by plugins, which is why I specifically added the second option as being a viable (truthfully, maybe even more viable) option. I had written all of the code to do this myself (code that could potentially have some performance impact because it had more logic than could be put into a TCC function and therefore had to be called or EXECSTR'd) because I considered it to be a requirement in the application that I am writing, code that will now be (happily!) abandoned. :)

    Oh, and I think that it is asymptotically reaching perfection; it is so close and yet so close! :)

    - Dan
     
  8. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    A suggestion not a complaint: Since you took the time to add the time functionality to the plugin (again, thank you very, very, much :)) you might want to mention that it's there on http://www.unm.edu/~cdye/plugins/index.html. Give yourself some credit and other people an idea that it's there if they have a need for it.

    - Dan
     

Share This Page