Try Catch expense and best practice

  1. 4 months ago

    Jim F

    May 14 Pre-Release Testers, Xojo Pro

    Hello,

    Normally I use Try/Catch for just one exception type and a narrow section of code. Looking at the future of Sockets they will use Try/Catch instead of checking True/False conditions. Is it better to have many Try/Catch loops in a method, or have most of the socket code in a larger scope with several catch types at the end? I assume one major reason for this change is code execution speed, not having to check for all the True/False conditions - assume all is well unless an exception is triggered.

    That being said, here is some example code:

    Dim mbTest As NEW MemoryBlock(10)
    Try
      mbTest.StringValue(9,5) = "Hello"
    Catch erData As NilObjectException
      MsgBox("Will not execute this, cause no Nil Object issues")
    Catch erData As RunTimeException
      MsgBox("Will execute this")
    Catch erData As OutOfBoundsException
      MsgBox("Yes, out of bounds; but won't execute this")
    End Try

    In the code above, Catch RunTimeException and Catch OutOfBoundsException need to switch places if you want to actually catch the Out of Bounds triggered by trying to write "ello" beyond the size of mbTest.

    Is RunTimeException the only catch ALL where something like this matters, or are their other catch types where the order is important?

    Thanks.

  2. Norman P

    May 14 Pre-Release Testers, Xojo Pro Answer great-white-software.com/blog
    Edited 4 months ago

    the only reason you need to swap the order is because RuntimeException is the parent class of all other exceptions so its like saying "catch everything" - so no more specific subtypes are caught after that

    as for "best practice" it really depends on the code, how it functions and what you expect to happen IF you catch an error or if you dont

    in a simple linear bit of code where you'd normally bail out an do nothing IF there was some error then just one try catch might suffice

    if its a loop where you are trying to do something repeatedly in the loop and want the loop to proceed even in the case you catch an error then you might have a try catch inside the loop

    Not sure there's a single "best" answer for all situations

  3. Tim P

    May 14 Pre-Release Testers Rochester, NY
    Edited 4 months ago

    @Jim F Is it better to have many Try/Catch loops in a method, or have most of the socket code in a larger scope with several catch types at the end?

    Whether you put the try catch inside a loop or outside a loop depends on the behavior you're looking for. If your loop can continue processing after handing an error, put the catch inside the loop.

    @Jim Frankland Is RunTimeException the only catch ALL where something like this matters, or are their other catch types where the order is important?

    RuntimeException is the superclass for all the others. As Norman mentioned, you're basically saying "Hey, I want everything here." Don't do that. If you're not catching a specific exception, you can't really handle it. Anything unhandled should bubble to UnhandledException -- where what is considered best practice seems to still be up for debate. My opinion is that terminating the app is best because it's an exception you haven't handled, you don't know what it is, or what effects it has. Safer to quit and start again.

    Catching exceptions is a different mindset than the older check for error codes. If you (or anyone!) have any other questions, I think this would be a great place to discuss best practices :)

  4. Norman P

    May 14 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    as Tim said, do not catch RuntimeException
    catch the things you CAN handle and do want to handle and let others go by

    "catch everything" is generally NOT really what you actually want to do

    and especially not "catch everything and ignore it"

  5. Christian S

    May 15 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

    Please don't catch RunTimeException.
    Catch the ones you explicit handle here.

  6. Tobias B

    May 15 Pre-Release Testers, Xojo Pro Bern, Switzerland
    Edited 4 months ago

    and if you happen to catch all exceptions, don't forget to re-raise the EndExceptions and ThreadEndExceptions. See: http://docs.xojo.com/Exception / http://docs.xojo.com/Try

  7. Paul M

    Jun 2 Pre-Release Testers, Xojo Pro Eastern Massachusetts, USA

    @Norman P as Tim said, do not catch RuntimeException

    Except for the unfortunate places in the old-new framework that raise a RuntimeException instead of a subclass, like:

    Xojo.IO.FolderItem.CreateAsFolder 
    Xojo.IO.SpecialFolder.ApplicationSupport 
    Xojo.Core.TextEncoding.ConvertTextToData
    etc.

    I really hope API 2.0 doesn't do that...

  8. Norman P

    Jun 2 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    Dunno but I suppose if its not that way them it can be raised when we see a beta

  9. Norman P

    Jun 2 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    Xojo.IO.FolderItem.CreateAsFolder - huh that probably should have been an IOException
    Xojo.IO.SpecialFolder.ApplicationSupport - same
    Xojo.Core.TextEncoding.ConvertTextToData - maybe a UnsupportedOperationException

    I'd file those as bug reports if they havent been already

  10. 6 weeks ago

    Charles W

    Aug 6 Pre-Release Testers, Xojo Pro Seattle, WA

    Reopening this thread to ask about best practices for CATCH properties. This is what I'm assuming is a really dumb question, but that's just the way I roll.

    If I have code like this (which is guaranteed to fail):

    try
      dim aa as dictionary
      aa.Value("foo") = "bar"
      MsgBox "All is as it was"
      
    Catch e As NilObjectException
      MsgBox "Whoops: " + e.Message + "  reason:" + e.Reason + "  #" +str(e.ErrorNumber)
    end try

    And I run it, the values for e.Message and e.Reason are blank, and e.ErrorNumber is zero.

    Is this normal? When should I expect to see useful information in these properties?

    I'm guessing I missed the semester where this was discussed; or, I'm just losing all my neurons.

    Thanks!

  11. Tim H

    Aug 6 Pre-Release Testers Portland, OR USA

    @Charles W Is this normal? When should I expect to see useful information in these properties?

    When the operating system provides it. Things like IOException will have more useful information. Or where you write your own exceptions and provide that information.

  12. Charles W

    Aug 6 Pre-Release Testers, Xojo Pro Seattle, WA

    Thanks Tim. So the catch properties only come from the OS?

    For example in NilObjectException, it would be fabulous if Xojo could put into the message something about the object which is Nil. Sometimes in a complex statement it takes a while to work out which one is the problem.

  13. Tim H

    Aug 6 Pre-Release Testers Portland, OR USA

    How would they give you information about an object that doesn't exist?

  14. Charles W

    Aug 6 Pre-Release Testers, Xojo Pro Seattle, WA

    Answering that is above my pay grade. I do know that in some other debuggers I've used over the decades, some of them provided more useful information about what the actual problem was, rather than just pointing to a line number.

  15. Markus W

    Aug 6 Pre-Release Testers #JeSuisHuman New Zealand, Auc...
    Edited 6 weeks ago

    If you are using try catch to test for a specific exception then you already know the exception type. So why not write

    MsgBox "Whoops: " + e.Message + " reason: NilObjectException in " + CurrentMethodName + " #" +Str(e.ErrorNumber)

    I put your code into a PushButton, and get

    Whoops: reason: NilObjectException in Window1.PushButton1.Action #0

    Personally I use a catch all, so I put your code into a PushButton, added my error code, and ran it:

    Dim aa As dictionary
    aa.Value("foo") = "bar"
    MsgBox "All is as it was"
    
    Exception err
    
    If Not Module_ErrorHandling.HandleException(err, CurrentMethodName) Then 
      Raise err // this lets me know exactly where the exception
    End If // happened and my message dialog reports this along
    // with what type of exception it was

    The module opens a window that shows:

    Sorry, but an error occured. It should not happen but unfortunately it has. Please report what you were doing before the program fell over.

    NilObjectException in Window1.PushButton1.Action

    and gives the user the options to (1) send an email with the stack and then (2) save the data as a new file (in the hope something can be recovered if needed)

  16. Markus W

    Aug 6 Pre-Release Testers #JeSuisHuman New Zealand, Auc...
    Edited 6 weeks ago

    @Tim H How would they give you information about an object that doesn't exist?

    Actually it is kinda possible.

    I added a property to my ErrorModule

    Public Property ErrorLocation as String = "Error location"

    Wherever I would have a try catch I would set (and reset) that property instead, so the code becomes

    ErrorLocation = "Dictionary aa"
    Dim aa As dictionary
    aa.Value("foo") = "bar"
    ErrorLocation = ""
    
    Exception err
      
      If Not Module_ErrorHandling.HandleException(err, CurrentMethodName) Then 
        Raise err // this lets me know exactly where the exception
      End If // happened and my message dialog reports this along
      // with what type of exception it was

    and my email now says:

    NilObjectException in Window1.PushButton1.Action

    Error probably caused by: Dictionary aa

    Btw you can simply sprinkle locations throughout your code:

    ErrorLocation = "Location 1"
    [some code]
    ErrorLocation = "Location 2"
    [some more code]
    ErrorLocation = "Location 3"
    [some more code]

    Getting

    Error probably caused by: Location 2

    tells you it is between Location 2 and 3

  17. Tobias B

    Aug 7 Pre-Release Testers, Xojo Pro Bern, Switzerland

    @Charles W Answering that is above my pay grade. I do know that in some other debuggers I've used over the decades, some of them provided more useful information about what the actual problem was, rather than just pointing to a line number.

    Improving the provided RuntimeException information is a long standing request. Some of them are listed here:

or Sign Up to reply!