Posts tagged: CLR

comments Comments (0)
By spgennard, August 22, 2010 4:13 pm

Last week I replied to a post about exceptions, it made me think those programming .Net daily take for granted the etiquette of using Exceptions. So I thought I would share some of my thoughts… well it is a sort of a rules’ish list.

  • Exceptions can be expensive, so avoid using them for normal conditions
  • Only catch the exceptions you can handle
  • Don’t hide/swallow exceptions
  • Don’t catch System.Exception as will also catch unmanaged exceptions such as System.Runtime.InteropServices.SEHException
  • Consider using your own custom exceptions or derive them from similar ones
  • Remember inner exceptions when processing an exception
  • Use the Exception suffix on your custom exception
  • Consider using Microsoft’s StyleCop to point out common issues
  • Avoid using System.ApplicationException if you want to use the code in the Silverlight CLR
  • Remember to serialize your own exception types
  • Use xml comment docs for the exceptions a method raises… it helps intellisense..

I suspect I might have missed something.. so feel free to comment..

categories CLR, Tips | tags , ,

Method Chaining

comments Comments (1)
By spgennard, May 28, 2010 12:50 am

Creating objects with a complex constructor can be a bit of a pain in any language. One technique I have used is method chaining. It is not applicable to every type of class but it can be useful.

Method chain can help simply the use class and allows more complex object initialisation without having to worry about the order of the parameters and be done inline.

Consider the use of an “Account” class that takes Name, Address, Telephone and Country. All of which are strings, the constructor with four strings would not be a great constructor.

So you could have a simple constructor and four properties/methods.. however so set up the object would mean you have spread the setup over multiple lines.

Using method chain you can overcome this and even space in the “value” area of the object in your storage area.

set x to new type Account::Name("xx")::Address("yy") ::Telephone("yy")
     ::Country("zz")::World("Earth")

The trick of the pattern is to provide methods that always return this/self, so we can change the invokes together… For example:

This technique could even be used to build up a series of items required, for example, the preparation and execution of a sql statement comes to mind… in a similar fashion to Linq.

So… lets look at an example:

$set ilusing"System.Collections.Generic"
program-id. Program1 as "MethodChaining1.Program1".
data division.
working-storage section.
01 accounts type List[type Account] value new type List[type Account].      
01 jAccount type Account value
   new type Account::Name("Mr Johnson")::Address("Somewhere, some place")
    ::Telephone("+44 1234 4321").
01 sAccount type Account value
   new type Account::Name("Mr Smith")::Address("Nowhere place")
     ::Telephone("+44 1234 4321")::Country("Wales").                
01 lAccount type Account.
procedure division.
 invoke accounts::Add(jAccount)
 invoke accounts::Add(sAccount)
 
 perform varying lAccount through accounts
  display lAccount
 end-perform

 goback.
end program.

WIth the class being:

class-id Account.

working-storage section.
01 wName       string property as "Name".
01 wAddres     string property as "Address".
01 wCountry    string property as "Country".
01 wTelephone  string property as "Telephone".
01 wEmail      string property as "Email".

method-id New.
local-storage section.
procedure division.
  set wCountry to type System.Globalization.RegionInfo::CurrentRegion::DisplayName
end method.

method-id Name public.
procedure division using uName as string
 returning ret as type Account.
  set self::Name to uName
  set ret to self
end method.

method-id Address public.
procedure division using uAddress as string
 returning ret as type Account.
  set self::Address to uAddress
  set ret to self
end method.

method-id Telephone public.
procedure division using uTelephone as string
 returning ret as type Account.
  set self::Address to uTelephone
  set ret to self
end method.

method-id Email public.
procedure division using uEmail as string
 returning ret as type Account.
  set self::Address to uEmail
  set ret to self
end method.

method-id Country public.
procedure division using uCountry as string
 returning ret as type Account.
  set self::Country to uCountry
  set ret to self
end method.

method-id ToString public override.
procedure division returning ret as string.
set ret to String::Format("Name:{0}, Address:{1}, Telephone:{2}, Email:{3}, Country:{4}",
     self::Name, self::Address, self::Telephone,
     self::Email, self::Country)
end method.
end class.

Which when run with Visual COBOL gives:

Name:Mr Johnson, Address:+44 1234 4321, Telephone:, Email:, Country:United Kingdom
Name:Mr Smith, Address:+44 1234 4321, Telephone:, Email:, Country:Wales

categories CLR, COBOL | tags , , , , , ,

Reflection and COBOL

comments Comments Off
By spgennard, February 13, 2010 11:56 pm

For the last couple of months I have working on Visual Studio 2010 and this include Microsoft CLR v4 and I was recently asked how to write a test that determines at runtime which CLR is being used and what assemblies it uses. I replies would use reflection. So I dropped my friend a mega simple demo… and here it is.

       $set ilusing"System.Reflection"

        01 myAssembly type "Assembly".
        01 usedAssemblyName type "AssemblyName".

        set myAssembly to type "Assembly"::"GetExecutingAssembly"

        display "My exe is " myAssembly::"FullName"
        display "and is using CLR " myAssembly::"ImageRuntimeVersion"
        display "and is loaded from " myAssembly::"Location"
        display "the initial method of this program was "
          myAssembly::"EntryPoint"::"Name"

        display "This assembly references -> "
        perform varying usedAssemblyName
             through myAssembly::"GetReferencedAssemblies"
              display "-> " usedAssemblyName
        end-perform

And the output of the program is:

My exe is clrver, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
and is using CLR v2.0.50727
and is loaded from d:\clrver.exe
the initial method of this program was _MF_ENTRYThis assembly references ->
-> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
-> MicroFocus.COBOL.Runtime, Version=3.6.0.0, Culture=neutral,
PublicKeyToken=0412c5e0b2aaa8f0

categories CLR, COBOL, Tips | tags , , , ,

Base Class Library, Arrays, Queues and Stacks

comments Comments Off
By spgennard, November 19, 2009 10:41 pm

Continuing the series of blogs about COBOL and the .Net base class library…

The .Net base class library has a wealth classes and an huge of amount of methods/properties.

The .Net base class library has a key handy namespace that contains are the lovely classes, which is System.Collections.

As you can see from the above link, it does have quite a lot, so for this blob entry I will look at:

  • arrays of numbers
  • queues
  • stacks

    • Lets start the first example by using an array of numbers… just to demonstrate its not just strings you can assign to the arrays using “values”.

           01 numbers  binary-long occurs 10
              values 10 20 30 40 50 10 20 30 40 50.

           01 num       binary-long value 0.
           01 average   binary-double value 0.

           procedure division.
              perform varying num through numbers
                add num to average
              end-perform
              divide average by numbers::"Length" giving average
              display "Average is : " average

    Running the above code gives us:

    Average is : +00000000000000000030

    The next class that is helpful, is the Queue class, this allows us to “Enqueue” and “Dequeue” item using the same methods, the queue is again displayed using the “perform through” syntax.

          $set ilusing"System"
          $set ilusing"System.Collections"

           01 alphabetQueue     type "Queue".
           01 item              object reference.

           set alphabetQueue to new type "Queue"()
           invoke alphabetQueue::"Enqueue"("A item")
           invoke alphabetQueue::"Enqueue"("B item")
           invoke alphabetQueue::"Enqueue"("C item")

           display "The initial queue is: "
           perform varying item through alphabetQueue
             display " " item
           end-perform

           display "".
           display "De-Queue an item: " alphabetQueue::"Dequeue"()

           display "".
           display "Afterwards is: "
           perform varying item through alphabetQueue
             display " " item
           end-perform

    Running the above queue example gives:

    The initial queue is:
     A item
     B item
     C item

    De-Queue an item: A item

    Afterwards is:
     B item
     C item

    Next, lets look at the ‘Stack’ class, this is very similar, expect it uses the “Push”, “Pop” methods and we iterate through the Stack using the ‘perform through’ syntax.

          $set ilusing"System"
          $set ilusing"System.Collections"

           01 alphabetStack     type "Stack".
           01 item              object reference.

           set alphabetStack to new type "Stack"()
           invoke alphabetStack::"Push"("A item")
           invoke alphabetStack::"Push"("B item")
           invoke alphabetStack::"Push"("C item")

           display "The initial stack is: "
           perform varying item through alphabetStack
             display " " item
           end-perform

           display "".
           display "Pop item: " alphabetStack::"Pop"()

           display "".
           display "Afterwards is: "
           perform varying item through alphabetStack
             display " " item
           end-perform

    Running the above stack example gives:

    The initial stack is:
     C item
     B item
     A item

    De-Stack an item: C item

    Afterwards is:
     B item
     A item

    As you can see using the base class library collection classes with COBOL is just as easy as using C#… so if you are already using COBOL… continue and try out the .Net base class library.. it really is very easy to use and it will make you more productive.. so please explore and enjoy .Net and its Base Class library.

    categories CLR, COBOL | tags , ,

    Detecting the use Mono CLR dynamically

    comments Comments Off
    By spgennard, November 17, 2009 9:25 pm

    While developing something that could be used on Mono on Windows, Mono on Unix and on Windows with Microsoft’s CLR, I needed to be sensitive to the environment but didn’t want to conditionally compile my code different. So I put together a quick class to help.. Below is the C# code with pics of it running on Windows/Mac…

    using System;
    using System.Reflection;

    namespace Gennard.Net
    {
        public class CLRUtils
        {
            private static readonly bool isMono= Type.GetType("Mono.Runtime") == null ? false : true;

            private static readonly int eOSp = (int)Environment.OSVersion.Platform;
            private static readonly bool isUnix =  (eOSp == 4) || (eOSp == 128);

            /* Class Properties */
            public static bool IsMono { get { return isMono; } }
            public static bool IsUnix { get { return isUnix; } }

            public static void Main()
            {
                Console.WriteLine("Are we using Mono? : "+IsMono);
                Console.WriteLine("Are we using Unix? : "+IsUnix);
            }
        }
    }

    The taste of the pudding mix.. is in the eating.. so lets see it working…

    On Windows....

    On the Mac, we get....

    categories CLR, CSharp, Mono, Tips | tags , ,

    Panorama Theme by Themocracy