The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,262 other subscribers

Archive for February 17th, 2021

How not to do updates of your wiki site

Posted by jpluimers on 2021/02/17

If your company manages your own infrastructure, be sure you have monitoring on all levels.

It saves you from customers discovering issues like this: [WayBack] Thread by @jpluimers: “The @EmbarcaderoTech docwiki is down due to an error in duobook2.[…]”:

The @EmbarcaderoTech docwiki is down due to an error in duobook2. URLs pointing to wiki content fail, no matter the product. Examples for Rio and XE2 grabbed from docwiki.embarcadero.com/Libraries/Rio/… and docwiki.embarcadero.com/Libraries/XE2/…


This is the #1 reason for allowing archival of all your product documentation web-content in the @internetarchive, even for non-current products, as now only parts that have been allowed to save in the past are available.

Apart from nobody noticing the outage yet, which is bad in it’s own way, I hope the cause is not somebody fiddling with duobook (3 year old and unmaintained) without testing the consequences. As that would make the cause of the outage embarrassing.

[WayBack] https://github.com/ElectricVersion/DuoBook

Finally it is rather odd to get a HTTP 200 SUCCESS code on a failure. A HTTP 500 or 503 would be far more appropriate.

I wonder if that is a @mediawiki thing; maybe they could shed some light on that.

References en.wikipedia.org/wiki/List_of_H… and en.wikipedia.org/wiki/List_of_H….

The cool thing is that the stack traces teach you a lot about how a framework is structured.

Related:

  • [Archive.is/WayBack] RAD Studio API Documentation: Rio
    Exception encountered, of type "ArgumentCountError"
    [6a5b64d3a502a9acff148fe1] /Libraries/Rio/en/Main_Page ArgumentCountError from line 420 of /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php: Too few arguments to function DuoBook2Template::displayPrefs(), 0 passed in /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php on line 99 and exactly 1 expected
    Backtrace:
    #0 /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php(99): DuoBook2Template->displayPrefs()
    #1 /var/www/html/shared/BaseWiki27/includes/skins/SkinTemplate.php(248): DuoBook2Template->execute()
    #2 /var/www/html/shared/BaseWiki27/includes/OutputPage.php(2335): SkinTemplate->outputPage()
    #3 /var/www/html/shared/BaseWiki27/includes/MediaWiki.php(743): OutputPage->output()
    #4 /var/www/html/shared/BaseWiki27/includes/MediaWiki.php(509): MediaWiki->main()
    #5 /var/www/html/shared/BaseWiki27/index.php(43): MediaWiki->run()
    #6 {main}
  • [Archive.is/WayBack] XE2 API Documentation
    Exception encountered, of type "ArgumentCountError"
    [d3d353581c3915881b976ab6] /Libraries/XE2/en/Main_Page ArgumentCountError from line 420 of /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php: Too few arguments to function DuoBook2Template::displayPrefs(), 0 passed in /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php on line 99 and exactly 1 expected
    Backtrace:
    #0 /var/www/html/shared/BaseWiki27/skins/DuoBook2/DuoBook2.php(99): DuoBook2Template->displayPrefs()
    #1 /var/www/html/shared/BaseWiki27/includes/skins/SkinTemplate.php(248): DuoBook2Template->execute()
    #2 /var/www/html/shared/BaseWiki27/includes/OutputPage.php(2335): SkinTemplate->outputPage()
    #3 /var/www/html/shared/BaseWiki27/includes/MediaWiki.php(743): OutputPage->output()
    #4 /var/www/html/shared/BaseWiki27/includes/MediaWiki.php(509): MediaWiki->main()
    #5 /var/www/html/shared/BaseWiki27/index.php(43): MediaWiki->run()
    #6 {main}

–jeroen

Read the rest of this entry »

Posted in Development, DevOps, Infrastructure, Power User, Software Development, Web Development | Leave a Comment »

explainshell.com: parse and explain just about any shell command

Posted by jpluimers on 2021/02/17

I bumped into the tremendously site [WayBack] explainshell.com – match command-line arguments to their help text only after documenting the relevant cURL options of yesterdays post on checking your CertBot domain expiration dates.

The site allows put in a shell command-line to see the help text that, including matches for each argument.

It works so well because it parses both the shell command-line and the man pages, then constructs a web-page linking the relevant man page content to the shell command-line in the correct shell command-line order.

The explainshell has a counterpart showthedocs (both are open source) for explaining other languages (on the one hand more extended as it goes much deeper into parsing for instance SQL, on the other hand more limited as it only supports a few languages). More on showthedocs later.

The links

The parsing results

The first bit below is just the text output, and the second bit the screenshot, of a relatively simple command like [WayBack] explainshell.com – curl -fsSL example.org:

curl(1) -fsSL example.org
transfer a URL
-f, --fail
       (HTTP)  Fail  silently  (no  output at all) on server errors. This is mostly done to better enable
       scripts etc to better deal with failed attempts. In normal cases  when  a  HTTP  server  fails  to
       deliver  a  document,  it  returns an HTML document stating so (which often also describes why and
       more). This flag will prevent curl from outputting that and return error 22.

       This method is not fail-safe and there are occasions where non-successful response codes will slip
       through, especially when authentication is involved (response codes 401 and 407).
-s, --silent
       Silent or quiet mode. Don't show progress meter or error messages.  Makes Curl mute.
-S, --show-error
       When used with -s it makes curl show an error message if it fails.
-L, --location
       (HTTP/HTTPS) If the server reports that the requested page  has  moved  to  a  different  location
       (indicated  with  a Location: header and a 3XX response code), this option will make curl redo the
       request on the new place. If used together with -i, --include or  -I,  --head,  headers  from  all
       requested pages will be shown. When authentication is used, curl only sends its credentials to the
       initial host. If a redirect takes curl to a different host, it won't  be  able  to  intercept  the
       user+password.  See  also  --location-trusted  on  how to change this. You can limit the amount of
       redirects to follow by using the --max-redirs option.

       When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will
       do  the  following  request  with a GET if the HTTP response was 301, 302, or 303. If the response
       code was any other 3xx code, curl will re-send the following request  using  the  same  unmodified
       method.
source manpages: curl

The screenshot is even more impressive:

Read the rest of this entry »

Posted in *nix, *nix-tools, bash, bash, Development, Power User, Scripting, Software Development | Leave a Comment »

DUnit testing code that should raise a specific exception

Posted by jpluimers on 2021/02/17

A while back, I was writing some code to demonstrate a few inner workings of TInterfacedObject, interface reference counting and mixing object references with interface references.

One way to show this is through a test case that expects a certain exception to happen, but I forgot how to do that in DUnit. Luckily this pointed me on the right track: [WayBack] delphi – CheckException only accepts 0-parameter methods; how do I test that other methods throw exceptions? – Stack Overflow.

The solution shows that DUnit has had support for something similar as DUnitX: now has a WillRaiseAttribute to ease defining tests around code that should throw exceptions for a very long time (I think this was introduced around Delphi 2005).

You can do it in a property way:

unit InterfacedObjectTestCaseUnit;

interface

uses
  TestFramework;

type
  TDebuggableInterfacedObjectTestCase = class(TTestCase)
  published
    procedure System_TInterfacedObject_Free_Before_RefCount_Should_Raise_EInvalidPointer();
  end;

implementation

uses
  System.SysUtils,

procedure TInterfacedObjectTestCase.System_TInterfacedObject_Free_Before_RefCount_Should_Raise_EInvalidPointer();
var
  ObjectReference:    System.TInterfacedObject;
  InterfaceReference: IInterface;
begin
  ObjectReference    := System.TInterfacedObject.Create();
  InterfaceReference := ObjectReference;
  ExpectedException  := System.SysUtils.EInvalidPointer;
  ObjectReference.Free(); // this should raise an exception in System.TInterfacedObject.BeforeDestruction, as it checks the RefCount to be zero
  // the below is optional; should not be reached. If it is reached, it will fail earlier than the encompassing `RunTest` method would
  ExpectedException := nil; // or `StopExpectingException();`
end;

end.

or in a method way for an exception that happens in the current method:

procedure TInterfacedObjectTestCase.System_TInterfacedObject_Free_Before_RefCount_Should_Raise_EInvalidPointer();
var
  ObjectReference:    System.TInterfacedObject;
  InterfaceReference: IInterface;
begin
  ObjectReference    := System.TInterfacedObject.Create();
  InterfaceReference := ObjectReference;
  StartExpectingException(System.SysUtils.EInvalidPointer);
  ObjectReference.Free(); // this should raise an exception in System.TInterfacedObject.BeforeDestruction, as it checks the RefCount to be zero
  // the below is optional; should not be reached. If it is reached, it will fail earlier than the encompassing `RunTest` method would
  StopExpectingException();
end;

The alternative using CheckException that will raise earlier, but also tests the results of a complete method which also has to be parameterless:

procedure TDebuggableInterfacedObjectTestCase.System_TInterfacedObject_Free_Before_RefCount();
var
  ObjectReference:    System.TInterfacedObject;
  InterfaceReference: IInterface;
begin
  ObjectReference    := System.TInterfacedObject.Create();
  InterfaceReference := ObjectReference;
  ObjectReference.Free(); // this should raise an exception in System.TInterfacedObject.BeforeDestruction, as it checks the RefCount to be zero
end;

procedure TDebuggableInterfacedObjectTestCase.System_TInterfacedObject_Free_Before_RefCount_Should_Raise_EInvalidPointer_TTestMethod_Based();
begin
  CheckException(System_TInterfacedObject_Free_Before_RefCount, System.SysUtils.EInvalidPointer);
end;

So I wrote a class helper based on TProc that allows you to test an anonymous method which usually has more fine grained testing potential.

Because of type compatibility, you have to call the inherited version of CheckException inside the new one:

unit TestCaseHelperUnit;

interface

uses
  System.SysUtils,
  TestFramework;

type
  TTestCaseHelper = class helper for TTestCase
  public
    procedure CheckException(const AProc: TProc; const AExceptionClass: TClass; const msg: string = '');
  end;

implementation

type
  TTestCaseInvoker = class
  strict private
    FProc: TProc;
  public
    constructor Create(const AProc: TProc);
    procedure Execute();
  end;

{ TTestCaseInvoker }

constructor TTestCaseInvoker.Create(const AProc: TProc);
begin
  inherited Create();
  FProc := AProc;
end;

procedure TTestCaseInvoker.Execute();
begin
  if Assigned(FProc) then
    FProc();
end;

procedure TTestCaseHelper.CheckException(const AProc: TProc; const AExceptionClass: TClass; const msg: string = '');
var
  TestCaseInvoker: TTestCaseInvoker;
begin
  TestCaseInvoker := TTestCaseInvoker.Create(AProc);
  try
    inherited CheckException(TestCaseInvoker.Execute, AExceptionClass, msg); // `inherited`, to avoid stack overflow because `TProc` is compatible with `TTestMethod`
  finally
    TestCaseInvoker.Free();
  end;
end;

end.

The test then becomes this:

procedure TDebuggableInterfacedObjectTestCase.System_TInterfacedObject_Free_Before_RefCount_Should_Raise_EInvalidPointer_TProc_Based();
var
  ObjectReference:    System.TInterfacedObject;
  InterfaceReference: IInterface;
begin
  ObjectReference    := System.TInterfacedObject.Create();
  InterfaceReference := ObjectReference;
  CheckException(procedure ()
  begin
    ObjectReference.Free(); // this should raise an exception in System.TInterfacedObject.BeforeDestruction, as it checks the RefCount to be zero
  end,
  System.SysUtils.EInvalidPointer);
end;

DUnit code snippets

Read the rest of this entry »

Posted in Agile, Conference Topics, Conferences, Delphi, Development, Event, Software Development, Unit Testing | Leave a Comment »