On Dec 3, 2006, at 2:24 AM, RBNUBE wrote:
I decided to go ahead an try this out myself. What I came up with
seems to
work. What are the pitfalls of this approach?
New Module:
ErrorTrapper
New Method in ErrorTrapper:
Error, with Parameters, Err as RunTimeException, Message as String,
Explanation as String, Icon as Integer, ActionText as String,
AlternateOn as
Boolean, AlternateText as String, CancelOn as Boolean)
<snick>
Main code example:
// NilObjectException
If file = nil or file.Exists = False then
Error(err, "Error reading file","File cannot be found.", 2,
"OK", True,
"", False)
Else
Continue
End If
Here you are confusing two fundamentally different types of
problems. You can and should check whether a FolderItem is nil
before using it. Thus a NilObjectException in such a case is your
fault. On the other hand, the existence of a FolderItem is not
entirely under your control; a file could be deleted by another
process, for example. Thus your code should anticipate this
possibility.
// OutOfBoundsException
Dim i, nFonts as Integer
nFonts=FontCount
For i=1 to nFonts //dont do this!
ListBox1.addrow(Font(i))
Next
Exception err
Error(err, "","", 2, "Skip", True, "Try Again", True)
The problem here is that the exception and subsequent jump may leave
your application in an unstable state. If you're not going to
attempt to handle errors in the method itself, probably the next best
response would be to put up an error message and quit.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
