What errors are not trappable?

[Howard Kaikow]

I'm using the code below, but an error is not getting trapped.
Where can such errors occur?
In another process?

Try
SomeCode
Catch ex As Exception
Dim strMsg() As String = Split(ex.ToString, vbCrLf)
With lstStuff
For i = 0 To UBound(strMsg)
.Items.Add(strMsg(i))
Next i
End With
End Try

 

[Herfried K. Wagner [MVP]]

I'm using the code below, but an error is not getting trapped.
Where can such errors occur?

What's the error message?

 

[Guest]

Only when an error occurs in somecode the code block under the catch
statement will be executed , is this your intention ?

regards

Michel Posseth [MCP]

 

[Howard Kaikow]

What's the error message?

THere is no message,

I'm trying to trap the error in the code I posted in my 24 June 2006 thread
Ghost 10 and VB 6 and VB .NE.

I've modified the code and added the following to the btnRunMe click evet
code.

Try
FindMyFiles(strFilename, i)
Catch ex As Exception
Dim strMsg() As String = Split(ex.ToString, vbCrLf)
With lstStuff
For i = 0 To UBound(strMsg)
.Items.Add(strMsg(i))
Next i
End With
End Try

 

[Howard Kaikow]

Only when an error occurs in somecode the code block under the catch
statement will be executed , is this your intention ?

Yes, but I believe that th ecode is being caused by Ghost's mount driver,
and I cannot trap the error.

 

[Jay B. Harlow [MVP - Outlook]]

Howard,
My understanding is that only "errors" that do not inherit from
System.Exception are not trappable. Or exceptions that cause the system to
"halt", such as OutOfMemory, StackOverflow, ExecutionEngineException. Some
exceptions, such as ThreadAbortException are trappable, however require
special means to stop (Thread.ResetAbort).


Especially when you use:

| Catch ex As Exception

However if you use:

| Catch

Then "errors" that do not inherit from System.Exception are trapped also.
Unfortunately you don't know what the exception is as it doesn't inherit
from System.Exception.

The only place I understand that you can get an "error" that does not
inherit from System.Exception is from C++.


I want to say this changed on .NET 2.0, that .NET 2.0 will wrap any "errors"
that do not inherit from System.Exception for you.



--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| I'm using the code below, but an error is not getting trapped.
| Where can such errors occur?
| In another process?
|
| Try
| SomeCode
| Catch ex As Exception
| Dim strMsg() As String = Split(ex.ToString, vbCrLf)
| With lstStuff
| For i = 0 To UBound(strMsg)
| .Items.Add(strMsg(i))
| Next i
| End With
| End Try
|
| --
| http://www.standards.com/; See Howard Kaikow's web site.
|
|

 

[Cor Ligthert [MVP]]

Jay,

I have seen some none trappable errors in the handling of the system.data
and by instance Date functions in version 1.x. In those functions there is
used the exception handler to handle some errors as functionality, and by
that making it outside those procedures not trappable anymore (where it was
as far as I remember me in the system.data something with null values). I
could see them by setting the option to break on any error.

I thought (hope) that this kind of programming is changed in version 2.0
(not with the date functions, that is well done)

Cor

 

[Howard Kaikow]

Howard,
My understanding is that only "errors" that do not inherit from
System.Exception are not trappable. Or exceptions that cause the system to
"halt", such as OutOfMemory, StackOverflow, ExecutionEngineException. Some
exceptions, such as ThreadAbortException are trappable, however require
special means to stop (Thread.ResetAbort).


Especially when you use:

| Catch ex As Exception

However if you use:

| Catch

Then "errors" that do not inherit from System.Exception are trapped also.
Unfortunately you don't know what the exception is as it doesn't inherit
from System.Exception.

Alas, at least with VB .NET 2003, Catch does not catch the error.

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
Where the errors being eaten by how data binding works?

I don't remember the specifics but I remember that some exceptions in
System.Data area are eaten by how data binding works.


Or the exception was getting by your exception handler?

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Jay,
|
| I have seen some none trappable errors in the handling of the system.data
| and by instance Date functions in version 1.x. In those functions there is
| used the exception handler to handle some errors as functionality, and by
| that making it outside those procedures not trappable anymore (where it
was
| as far as I remember me in the system.data something with null values). I
| could see them by setting the option to break on any error.
|
| I thought (hope) that this kind of programming is changed in version 2.0
| (not with the date functions, that is well done)
|
| Cor
|
| "Jay B. Harlow [MVP - Outlook]" <[email protected]> schreef in
| bericht | > Howard,
| > My understanding is that only "errors" that do not inherit from
| > System.Exception are not trappable. Or exceptions that cause the system
to
| > "halt", such as OutOfMemory, StackOverflow, ExecutionEngineException.
Some
| > exceptions, such as ThreadAbortException are trappable, however require
| > special means to stop (Thread.ResetAbort).
| >
| >
| > Especially when you use:
| >
| > | Catch ex As Exception
| >
| > However if you use:
| >
| > | Catch
| >
| > Then "errors" that do not inherit from System.Exception are trapped
also.
| > Unfortunately you don't know what the exception is as it doesn't inherit
| > from System.Exception.
| >
| > The only place I understand that you can get an "error" that does not
| > inherit from System.Exception is from C++.
| >
| >
| > I want to say this changed on .NET 2.0, that .NET 2.0 will wrap any
| > "errors"
| > that do not inherit from System.Exception for you.
| >
| >
| >
| > --
| > Hope this helps
| > Jay B. Harlow [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | I'm using the code below, but an error is not getting trapped.
| > | Where can such errors occur?
| > | In another process?
| > |
| > | Try
| > | SomeCode
| > | Catch ex As Exception
| > | Dim strMsg() As String = Split(ex.ToString, vbCrLf)
| > | With lstStuff
| > | For i = 0 To UBound(strMsg)
| > | .Items.Add(strMsg(i))
| > | Next i
| > | End With
| > | End Try
| > |
| > | --
| > | http://www.standards.com/; See Howard Kaikow's web site.
| > |
| > |
| >
| >
|
|

 

[Cor Ligthert [MVP]]

Jay,

It comes ever time more near, but I have checked it as far as I could see,
and it was because there was internaly used a try and catch.

You ask yourself maybe how I could see that. Just because there was a little
stop the first time when it did occur, that was the reason I investigated
it. It was by somebody in one of these newsgroups, I did not have the
problem, so it was only a small test which is already destroyed a long time
ago.

Cor
..

Cor,
Where the errors being eaten by how data binding works?

I don't remember the specifics but I remember that some exceptions in
System.Data area are eaten by how data binding works.


Or the exception was getting by your exception handler?

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Jay,
|
| I have seen some none trappable errors in the handling of the
system.data
| and by instance Date functions in version 1.x. In those functions there
is
| used the exception handler to handle some errors as functionality, and
by
| that making it outside those procedures not trappable anymore (where it
was
| as far as I remember me in the system.data something with null values).
I
| could see them by setting the option to break on any error.
|
| I thought (hope) that this kind of programming is changed in version
2.0
| (not with the date functions, that is well done)
|
| Cor
|
| "Jay B. Harlow [MVP - Outlook]" <[email protected]> schreef
in
| bericht | > Howard,
| > My understanding is that only "errors" that do not inherit from
| > System.Exception are not trappable. Or exceptions that cause the
system
to
| > "halt", such as OutOfMemory, StackOverflow, ExecutionEngineException.
Some
| > exceptions, such as ThreadAbortException are trappable, however
require
| > special means to stop (Thread.ResetAbort).
| >
| >
| > Especially when you use:
| >
| > | Catch ex As Exception
| >
| > However if you use:
| >
| > | Catch
| >
| > Then "errors" that do not inherit from System.Exception are trapped
also.
| > Unfortunately you don't know what the exception is as it doesn't
inherit
| > from System.Exception.
| >
| > The only place I understand that you can get an "error" that does not
| > inherit from System.Exception is from C++.
| >
| >
| > I want to say this changed on .NET 2.0, that .NET 2.0 will wrap any
| > "errors"
| > that do not inherit from System.Exception for you.
| >
| >
| >
| > --
| > Hope this helps
| > Jay B. Harlow [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | I'm using the code below, but an error is not getting trapped.
| > | Where can such errors occur?
| > | In another process?
| > |
| > | Try
| > | SomeCode
| > | Catch ex As Exception
| > | Dim strMsg() As String = Split(ex.ToString, vbCrLf)
| > | With lstStuff
| > | For i = 0 To UBound(strMsg)
| > | .Items.Add(strMsg(i))
| > | Next i
| > | End With
| > | End Try
| > |
| > | --
| > | http://www.standards.com/; See Howard Kaikow's web site.
| > |
| > |
| >
| >
|
|

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
| It comes ever time more near, but I have checked it as far as I could see,
| and it was because there was internaly used a try and catch.
If there was an internal try/catch, then the exception never got to your
code, that's what I mean by saying data binding "ate" (the exception was
eaten).

Processes that have a try/catch & eat exceptions can be problematic as your
code may never see the exception.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Jay,
|
| It comes ever time more near, but I have checked it as far as I could see,
| and it was because there was internaly used a try and catch.
|
| You ask yourself maybe how I could see that. Just because there was a
little
| stop the first time when it did occur, that was the reason I investigated
| it. It was by somebody in one of these newsgroups, I did not have the
| problem, so it was only a small test which is already destroyed a long
time
| ago.
|
| Cor
| .
| "Jay B. Harlow [MVP - Outlook]" <[email protected]> schreef in
| bericht | > Cor,
| > Where the errors being eaten by how data binding works?
| >
| > I don't remember the specifics but I remember that some exceptions in
| > System.Data area are eaten by how data binding works.
| >
| >
| > Or the exception was getting by your exception handler?
| >
| > --
| > Hope this helps
| > Jay B. Harlow [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | Jay,
| > |
| > | I have seen some none trappable errors in the handling of the
| > system.data
| > | and by instance Date functions in version 1.x. In those functions
there
| > is
| > | used the exception handler to handle some errors as functionality, and
| > by
| > | that making it outside those procedures not trappable anymore (where
it
| > was
| > | as far as I remember me in the system.data something with null
values).
| > I
| > | could see them by setting the option to break on any error.
| > |
| > | I thought (hope) that this kind of programming is changed in version
| > 2.0
| > | (not with the date functions, that is well done)
| > |
| > | Cor
| > |
| > | "Jay B. Harlow [MVP - Outlook]" <[email protected]> schreef
| > in
| > | bericht | > | > Howard,
| > | > My understanding is that only "errors" that do not inherit from
| > | > System.Exception are not trappable. Or exceptions that cause the
| > system
| > to
| > | > "halt", such as OutOfMemory, StackOverflow,
ExecutionEngineException.
| > Some
| > | > exceptions, such as ThreadAbortException are trappable, however
| > require
| > | > special means to stop (Thread.ResetAbort).
| > | >
| > | >
| > | > Especially when you use:
| > | >
| > | > | Catch ex As Exception
| > | >
| > | > However if you use:
| > | >
| > | > | Catch
| > | >
| > | > Then "errors" that do not inherit from System.Exception are trapped
| > also.
| > | > Unfortunately you don't know what the exception is as it doesn't
| > inherit
| > | > from System.Exception.
| > | >
| > | > The only place I understand that you can get an "error" that does
not
| > | > inherit from System.Exception is from C++.
| > | >
| > | >
| > | > I want to say this changed on .NET 2.0, that .NET 2.0 will wrap any
| > | > "errors"
| > | > that do not inherit from System.Exception for you.
| > | >
| > | >
| > | >
| > | > --
| > | > Hope this helps
| > | > Jay B. Harlow [MVP - Outlook]
| > | > .NET Application Architect, Enthusiast, & Evangelist
| > | > T.S. Bradley - http://www.tsbradley.net
| > | >
| > | >
| > | > | > | > | I'm using the code below, but an error is not getting trapped.
| > | > | Where can such errors occur?
| > | > | In another process?
| > | > |
| > | > | Try
| > | > | SomeCode
| > | > | Catch ex As Exception
| > | > | Dim strMsg() As String = Split(ex.ToString, vbCrLf)
| > | > | With lstStuff
| > | > | For i = 0 To UBound(strMsg)
| > | > | .Items.Add(strMsg(i))
| > | > | Next i
| > | > | End With
| > | > | End Try
| > | > |
| > | > | --
| > | > | http://www.standards.com/; See Howard Kaikow's web site.
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|

 

[Howard Kaikow]

Processes that have a try/catch & eat exceptions can be problematic as your
code may never see the exception.

I could be running into that situation, but I have conflicting info.
The problem I am having is described at
http://www.standarrds.com/index.html?GhostIssueFindFiles.

Ghost 10 requires .NET Framework 1.1, so it is possible that Ghost is
trapping errors in .NET code.
But, somebody has stated that Ghost 10 uses .NET only for the GUI and not
for the drivers that handle mounted volumes.

I am still suspicious of this as I found a VB .NET example in a VB .NET book
that uses the Framework, not the API, to access the volumes. For ALL
volumes, this program raises an exception due to timing issues with changes
in the System Volume Information directory. So, I expect that the code has
to be modified to better handle that exception.

Perhaps, Ghost 10 is using .NET for the driver for Ghost mounted volumes,
and is just messing up the error handling, but only for certain volumes (the
most volatile volumes).

I have NO problems with the real logical volumes, or those mounted by
Acronis True Image, so I am still suspicious of whether Ghost 10 is using
..NET for mounted volume driver code.