Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Handling Exceptions

  1. #11
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    One of my basic coding rules is a function should never be longer than a page.

    Each function should have a description of what it does and an example of its syntax.

    As I mentioned before I think that a function or series of functions could be developed and placed into its own class that would handle all of the exceptions for arguments.

    I would be interested in discussing this and coming up with a class for handling that.

    That way the handling of the exceptions would not cloud the example, and the exception codes would be generated, and it would be easy to add exception handling to any routine.

    Function specification

    As I see it, the array of arguments, an array holding the data types for each argument, array of optional (default values) and a flag that would tell the routine to display the error messages to the command line in AutoCAD, the console in the development environment, record them into a file, or do not display them at all also maybe a protection mode that helps the data types to strings etc...

    I could see the function returning an array of arguments or (nothing) before moving on through the routine.

    Also one of friends at AU (Scott McFarlane) in his lecture emphasized the need to not mix AutoCAD dependent functions with other generic functions.

    I interpreted that and applied that to LISP functions and pure .NET functions.

    I prefer to make the LISPMethod function call the pure .NET function.

    Do you have any suggestions or opinions on these ideas?



    DO you have any robust exception handling functions?
    AutomateCAD

  2. #12
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    I was thinking of something similar. I.e. a class working in the opposite direction as the ObjectToTypedValue class in the other thread. This should convert the result buffer into its object(s) - perhaps some list/array.

    While it's at it, it should also check to see if the correct types are found in the resbuf as was expected. Unfortunately this last aspect is very complex to achieve (especially for a general purpose class). There may be infinite combination possibilities, e.g. some argument might be allowed to be more than one type (e.g. int and real). Another argument might be allowed to be omitted. You'd need some way of telling this ResBuf->ObjectList class just what you're expecting so it can check the input against those rules.
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  3. #13
    Programming Moderator BlackBox's Avatar
    Join Date
    2009-11
    Posts
    5,500
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    I'm really struggling to understand this; I'd be remiss if I didn't also point out the irony here.

    Some have all but balked at the suggestion that basic Exception handling be implemented in the LispFunction Methods being offered, yet somehow a new, indeterminably complex Class structure to handle each-and-every-single-possible Exception potentiality (which would most assuredly be longer than one page, of unknown font size, font style, and page margins, etc.) is worthwhile?

    Would it not be preferable to simply implement basic code logic to throw one or more basic *LispExceptions (i.e., TooFewArgs, TooManyArgs, ArgumentType, etc.), in addition to any custom *LispException Types that derive from same, in order to scrub a given LispFunction Method's ResultBuffer for the required or allowed argument(s)?

    Never mind the fact that even if such an all-inclusive Exception handling Class existed, you'd still need sufficient code logic to feed this Type's constructors the appropriate parameters (where you'd normally just throw the aforementioned *LispExceptions).
    Last edited by BlackBox; 2014-02-20 at 02:35 PM.
    "How we think determines what we do, and what we do determines what we get."

    Sincpac C3D ~ Autodesk Exchange Apps

    Computer Specs:
    Dell Precision 3620, Core i7-7700K 4.2GHz, 64GB RAM, Samsung 970 Pro M.2, 8GB NVIDIA Quadro P4000

  4. #14
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    The principle is to get rid of as much noise as possible. E.g. say you create a LispFunction which should take a number (int/double) and a string. You spend most of that function on converting & testing the arguments (if you're using exceptions or not). E.g.
    Code:
            [LispFunction ("myfunction1")]
            public object myfunction1(ResultBuffer arguments) {
                try {
                    TypedValue[] args = arguments.AsArray();
                    if (args.Length != 2) throw new LispArgumentCountException(2, args.Length);
                    if (!((args[0].TypeCode == (int)LispDataType.Int16) ||
                          (args[0].TypeCode == (int)LispDataType.Int32) ||
                          (args[0].TypeCode == (int)LispDataType.Double)))
                        throw new LispArgumentException("Expecting int/double", args[0]);
                    if (args[1].TypeCode != (int)LispDataType.Text)
                        throw new LispArgumentException("Expecting string", args[1]);
                    double myNumber = (double)args[0].Value; // Get the actual value of the 1st argument
                    string myText = (string)args[1].Value; // Get the actual value of the 2nd argument
                    // Do some actual stuff
                    return "success";
                } catch (LispException e) {
                    return e.Message;
                }
            }
    The principle would be to have a handler class which would perform the tests and convert the TypedValues for you. Then you'd use it like this:
    Code:
            [LispFunction ("myfunction2")]
            public object myfunction2(ResultBuffer arguments) {
                try {
                    LispFunctionArgumentHandler args = new LispFunctionArgumentHandler
                        (arguments, new string[]{"Int16|Int32|Double", "Text"});
                    double myNumber = (double)args[0]; // Get the actual value of the 1st argument
                    string myText = (string)args[1]; // Get the actual value of the 2nd argument
                    // Do some actual stuff
                    return "success";
                } catch (LispException e) {
                    return e.Message;
                }
            }
    See how the type checking is reduced to a single instruction? What would be nice is if such handler would use something like generics to do the conversion as well - thus the get items would be something like this:
    Code:
                    double myNumber = args[0]; // Get the actual value of the 1st argument
                    string myText = args[1]; // Get the actual value of the 2nd argument
    Or I could do something using argument overloads, but I think the use thereof would be less succinct:
    Code:
                    double myNumber;
                    args.Get(0, out myNumber);
                    string myText;
                    args.Get(1, out myText);
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  5. #15
    Programming Moderator BlackBox's Avatar
    Join Date
    2009-11
    Posts
    5,500
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    Please correct me where I'm wrong....

    I'm understanding this discussion to have implicitly identified two entirely separate aspects, my zef-slang brotha' (who's having a birthday ehhhehehehehe).

    The first, implementing a Class to what I'd call 'scrub' the ResultBuffer for allowed arguments, both in number, and type(s).

    The second, implementing a Class to catch/handle all exceptions thereafter in the main code, in order to avoid empty catch statements.

    The former is quite simple in concept, just will require myriad constructor overloads in order to support each possible ResultBuffer configuration (we'd have to add them as we go, etc.). The latter however, either isn't possible via exposed API features, or I'm utterly unaware of how to go about it (which is entirely possible). Does this make (more?) sense, or am I really just off-base here?

    Cheers
    "How we think determines what we do, and what we do determines what we get."

    Sincpac C3D ~ Autodesk Exchange Apps

    Computer Specs:
    Dell Precision 3620, Core i7-7700K 4.2GHz, 64GB RAM, Samsung 970 Pro M.2, 8GB NVIDIA Quadro P4000

  6. #16
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    In my view the first class (mentioned above) is relatively easy.

    The arguments I see as necessary include...

    1.) Array of typed values, Or a result buffer that is immediately converted to an array of typedvalues.

    2.) Array of lispdatatypes for each argument specified, although some might accept multiple typed values like Double, int32 and int16. (see data conversion comment below)

    3.) Array of typedvalues as default values. Those arguments that do not have default values would be indicated with a nothing.

    4.) Bit Flags that instruct
    0 ) The function to not do any correction
    1 ) Instruct routine to try to convert argument to correct lispdatatype
    2 ) Type error messages to command line in AutoCAD
    4 ) Type error messages to console in development environment
    8 ) etc...

    The function would return an array of typedvalues that include the default values, or return nothing (after reporting the error)

    As far as the second item, in lisp it is possible to capture the expression that causes an error. This is because it can be compiled during runtime (eval).

    In conversations with Kean a couple years ago, he mentioned that compile at runtime (the evaluate expression) would be reintroduced in .net 5.0 after being removed in vb6 to vb.net conversion.

    With its reintroduction it would be possible to capture the expression and the error message and report it.
    It may be this second function might not be able to be coded until then.
    As I see the second function it would need to report the error, the offending expression and continue on with the routine.

    Or something like that.

    In conversations with a friend who is a professional programmer using Pearl, datatypes are very forgiving, allowing you to use "0" and 0 and the program knows that you are referring to 0.

    Conversion of datatypes to expected values has precedence in other languages, so enabling functions to convert data to strings,(if a string is required) isn't that different.
    AutomateCAD

  7. #17
    Certifiable AUGI Addict irneb's Avatar
    Join Date
    2015-11
    Location
    Jo'burg SA
    Posts
    4,512
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    Quote Originally Posted by peter View Post
    In conversations with a friend who is a professional programmer using Pearl, datatypes are very forgiving, allowing you to use "0" and 0 and the program knows that you are referring to 0.
    Yes, well - Perl is known (similar to PHP) for it's even weaker typing than Lisp.

    BTW, you can add some implied casting operators to give C# the ability to convert to/from strings into ints/reals quite easily. http://msdn.microsoft.com/en-us/library/z5z9kes2.aspx
    Sorry, never tried this in VB before - might probably be possible there too. E.g. here's a to-and-from double/string:
    Code:
            public static implicit operator double(string text) {
                double result;
                return double.TryParse(text, out result) ? result : double.NaN;
            }
            
            public static implicit operator string(double number) {
                return string.Format("{0:R}", number);
            }
    If that forms part of any public class you've loaded / referenced then the following would work:
    Code:
    double number = "1234.5678";
    string text = 1234.5678;
    Knowledge is proportional to experience, but wisdom is inversely proportional to ego!
    My little bit of "wisdom": Hind-sight is useless, unless used to improve the next forethought!

  8. #18
    Programming Moderator BlackBox's Avatar
    Join Date
    2009-11
    Posts
    5,500
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    Grrr... I could have sworn that Tony posted a Class which specifically converted ResultBuffer to List<TypedValue> (using generics?), and then back again, etc., which I cannot seem to locate at the moment.
    "How we think determines what we do, and what we do determines what we get."

    Sincpac C3D ~ Autodesk Exchange Apps

    Computer Specs:
    Dell Precision 3620, Core i7-7700K 4.2GHz, 64GB RAM, Samsung 970 Pro M.2, 8GB NVIDIA Quadro P4000

  9. #19
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    Yes, well - Perl is known (similar to PHP) for it's even weaker typing than Lisp.
    It is funny that the innuendo on the word 'weaker' implies less than.

    In my frame of reference protection of the routine/database is my number one imperative, so making arguments bullet proof would be stronger not weaker.

    IMHO, and much to be desired not avoided.

    I know many programmers who think everything is speed at run time, but in the production drafting world, speed for development usually governs.

    Peter
    AutomateCAD

  10. #20
    Past Vice President / AUGI Volunteer peter's Avatar
    Join Date
    2000-09
    Location
    Honolulu Hawaii
    Posts
    1,029
    Login to Give a bone
    0

    Default Re: Handling Exceptions

    Also I have been playing with a new routine, but I need to return a list of sublists ( as a result buffer).

    I have been playing around with Lists, Arrays, Structures, but nothing has the versatility of a LISP List.

    Suggestions or examples?

    I want to be able to manipulate one of the above data types in .net and convert it to a result buffer as a return value.

    I want each cell in the 2d array to contain any of the object types.

    P=
    AutomateCAD

Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. Better handling of bid packages
    By IanR in forum Revit Architecture - Wish List
    Replies: 0
    Last Post: 2010-03-12, 05:56 AM
  2. Error Handling
    By ticad02 in forum AutoLISP
    Replies: 16
    Last Post: 2009-12-21, 03:39 PM
  3. Handling Revisions
    By dbaldacchino in forum Revit Architecture - Tips & Tricks
    Replies: 3
    Last Post: 2006-12-15, 03:23 AM
  4. Handling Addendums
    By jmessner in forum Revit Architecture - General
    Replies: 8
    Last Post: 2006-10-11, 02:34 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •