How to avoid first time exceptions when calling a webmethod ?

[Olivier BESSON]

Hello,

VB.NET 1.1
IIS 6

I'm developping a winform client app of a web service of mine.

I used to set the IDE with "halt in debugger" on "common language runtime
exceptions".
Every time i call a method of my service if have 2 first time exceptions
"System.ObjectDisposedException" and "System.IO.IOException" in system.dll.
I'm on a french system so my translations of theses 2 messages is
"unable to access a deleted object named 'System.Net.TlsStream'" for the
first and "unabled to read transport connection datas" for the second.
After my calls, if i wait so time doing nothing i also have a
"System.Net.SocketsException" again in system.dll ("a remote connnection
have been closed by remote host").

These exceptions are handled somewhere in the framework and everything works
fine for my client app but they are terribly annoying me in my debugging
process.

What are theses exceptions : i think (hope ?) they are not "dangerous" since
they are caught and my app seems ok ?
Is there a way to code a ws client to have no "false" exceptions by doing
the work "properly" ?

Thanks in advance for your reply and sorry for my english

Olivier

[John Saunders [MVP]]

"Olivier BESSON" <o.******@community.nospamwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...

Hello,

VB.NET 1.1
IIS 6

I'm developping a winform client app of a web service of mine.

I used to set the IDE with "halt in debugger" on "common language runtime
exceptions".
Every time i call a method of my service if have 2 first time exceptions
"System.ObjectDisposedException" and "System.IO.IOException" in
system.dll.
I'm on a french system so my translations of theses 2 messages is
"unable to access a deleted object named 'System.Net.TlsStream'" for the
first and "unabled to read transport connection datas" for the second.
After my calls, if i wait so time doing nothing i also have a
"System.Net.SocketsException" again in system.dll ("a remote connnection
have been closed by remote host").

These exceptions are handled somewhere in the framework and everything
works fine for my client app but they are terribly annoying me in my
debugging process.

What are theses exceptions : i think (hope ?) they are not "dangerous"
since they are caught and my app seems ok ?
Is there a way to code a ws client to have no "false" exceptions by doing
the work "properly" ?

Thanks in advance for your reply and sorry for my english

I would suggest that you not halt in the debugger when exceptions are
thrown, but only when they are not caught. If the framework is catching
these exceptions, then why do you care about that?
--
John Saunders [MVP]

[Olivier BESSON]

"John Saunders [MVP]" <john.saunders at trizetto.coma écrit dans le
message de news: eE**************@TK2MSFTNGP03.phx.gbl...

"Olivier BESSON" <o.******@community.nospamwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...

>Hello,

VB.NET 1.1
IIS 6

I'm developping a winform client app of a web service of mine.

I used to set the IDE with "halt in debugger" on "common language runtime
exceptions".
Every time i call a method of my service if have 2 first time exceptions
"System.ObjectDisposedException" and "System.IO.IOException" in
system.dll.
I'm on a french system so my translations of theses 2 messages is
"unable to access a deleted object named 'System.Net.TlsStream'" for the
first and "unabled to read transport connection datas" for the second.
After my calls, if i wait so time doing nothing i also have a
"System.Net.SocketsException" again in system.dll ("a remote connnection
have been closed by remote host").

These exceptions are handled somewhere in the framework and everything
works fine for my client app but they are terribly annoying me in my
debugging process.

What are theses exceptions : i think (hope ?) they are not "dangerous"
since they are caught and my app seems ok ?
Is there a way to code a ws client to have no "false" exceptions by doing
the work "properly" ?

Thanks in advance for your reply and sorry for my english

I would suggest that you not halt in the debugger when exceptions are
thrown, but only when they are not caught. If the framework is catching
these exceptions, then why do you care about that?
--
John Saunders [MVP]

First and most important reason : because i want to halt on all exceptions
raised by my code, and even if they are in a dll class library of mine, just
to make sure that i handle it correctly.
Second, because sometimes seeing an unhandled exception makes me modifying
my code to do a "better way" the same thing (even if it's work) like when
you do a lot of databindings but here, i'm very knew to web services and i
don't know where to put "better" code to have no exceptions (if it is
possible).

Thansk

Olivier

[John Saunders [MVP]]

"Olivier BESSON" <o.******@community.nospamwrote in message
news:Ok**************@TK2MSFTNGP04.phx.gbl...

>
"John Saunders [MVP]" <john.saunders at trizetto.coma écrit dans le
message de news: eE**************@TK2MSFTNGP03.phx.gbl...

>"Olivier BESSON" <o.******@community.nospamwrote in message
news:eM**************@TK2MSFTNGP02.phx.gbl...

>>Hello,

VB.NET 1.1
IIS 6

I'm developping a winform client app of a web service of mine.

I used to set the IDE with "halt in debugger" on "common language
runtime exceptions".
Every time i call a method of my service if have 2 first time exceptions
"System.ObjectDisposedException" and "System.IO.IOException" in
system.dll.
I'm on a french system so my translations of theses 2 messages is
"unable to access a deleted object named 'System.Net.TlsStream'" for the
first and "unabled to read transport connection datas" for the second.
After my calls, if i wait so time doing nothing i also have a
"System.Net.SocketsException" again in system.dll ("a remote connnection
have been closed by remote host").

These exceptions are handled somewhere in the framework and everything
works fine for my client app but they are terribly annoying me in my
debugging process.

What are theses exceptions : i think (hope ?) they are not "dangerous"
since they are caught and my app seems ok ?
Is there a way to code a ws client to have no "false" exceptions by
doing the work "properly" ?

Thanks in advance for your reply and sorry for my english

I would suggest that you not halt in the debugger when exceptions are
thrown, but only when they are not caught. If the framework is catching
these exceptions, then why do you care about that?
--
John Saunders [MVP]

First and most important reason : because i want to halt on all exceptions
raised by my code, and even if they are in a dll class library of mine,
just to make sure that i handle it correctly.
Second, because sometimes seeing an unhandled exception makes me modifying
my code to do a "better way" the same thing (even if it's work) like when
you do a lot of databindings but here, i'm very knew to web services and i
don't know where to put "better" code to have no exceptions (if it is
possible).

I didn't say to not break on unhandled exceptions. I said to stop breaking
on _all_ exceptions, handled or not. You're finding that some code,
including Framework code, throws exceptions. That's totally irrelevant to
you unless the exception is not caught.
--
John Saunders [MVP]

[Steven Cheng[MSFT]]

Hi Olivier,

Regarding on the first chance exception you got, it indicate that there
occur some problem at network layer. Have you used https/ssl for your
webservice communiation here as the exception include tlsstream? For such
webservice communication, the underlying network library will monitor any
connection timeout or secure channel refresh, and these operations may
depend on some exceptions to trigger them.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

[Olivier BESSON]

Hello,

Yes i use https with NTLM auth but i have also runtime exceptions with http.
I also noted first chance runtime exceptions when running the web service in
debug mode :
"System.ArgumentException" in mscorlib.dll "link error with destination
method".

Is there a way (preferably simple) to do myself what is done hidden by the
runtime to be sure of why theses exceptions are raised and that i'm doing
the job properly.
I'm sure theses exceptions are well handled since all client and server
works but to much times i had to put my hands in old code that worked during
years to repair just a small bad coding, so i prefer to do all things right
the first (and only ?) time.

Thanks,

Olivier
"Steven Cheng[MSFT]" <st*****@online.microsoft.coma écrit dans le message
de news: 3j**************@TK2MSFTNGHUB02.phx.gbl...

Hi Olivier,

Regarding on the first chance exception you got, it indicate that there
occur some problem at network layer. Have you used https/ssl for your
webservice communiation here as the exception include tlsstream? For such
webservice communication, the underlying network library will monitor any
connection timeout or secure channel refresh, and these operations may
depend on some exceptions to trigger them.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no
rights.

[John Saunders [MVP]]

"Olivier BESSON" <o.******@community.nospamwrote in message
news:eM*************@TK2MSFTNGP02.phx.gbl...

Hello,

Yes i use https with NTLM auth but i have also runtime exceptions with
http.
I also noted first chance runtime exceptions when running the web service
in debug mode :
"System.ArgumentException" in mscorlib.dll "link error with destination
method".

Is there a way (preferably simple) to do myself what is done hidden by the
runtime to be sure of why theses exceptions are raised and that i'm doing
the job properly.
I'm sure theses exceptions are well handled since all client and server
works but to much times i had to put my hands in old code that worked
during years to repair just a small bad coding, so i prefer to do all
things right the first (and only ?) time.

These exceptions have nothing to do with you or your code.

Here's an analogy. What if you had another class, with a method like this:

try
{
throw new Exception("Return zero anyway");
}
catch (Exception ex)
{
return 0;
}

Code that calls this method has no need to know that an exception is thrown
inside of the method. The calling code will always receive the same answer.

What you've set in the debugger says that you need to know that some other
piece of code throws an exception as part of its normal, successful
functioning. That makes no sense at all.

These exceptions aren't being _hidden_ by the runtime. They are being thrown
by, and _handled_ by the runtime. Ignore them.
--
John Saunders [MVP]

[Olivier BESSON]

I'm sorry, but you've made a very serious mistake. You should NOT be

concerned with how any other piece of code implements itself. This is the
basic principal of encapsulation in OO. In particular, if some piece of
code happens to implement its logic by throwing and catching exceptions,
it's NOT YOUR CONCERN.

OK for other piece of code but not for my pieces of code.

>
I have never heard of anybody using your methodology, and I think it's one
of the worse techniques I've ever heard of. I have to assume that it's due
to a fundamental misunderstanding of exception handling.

It's my methodoly, maybe it's the worst technique of the world, but the fact
and my concern is this one :
I have to make applications for my company internal user.
Theses applications must have no bugs, must NEVER NEVER crash in production
and must do all the work or no work and inform user.
You'll say : "the same things are requested for all applications".
I'll respond : Yes but i know can you tell how many you know in this case ?
Personnaly, i think you can count it on one hand fingers (french expression
may not the same in english).
My results today is that all my company apps respect 99.999999999999999999%
of theses requests and they are really living things with not less than one
version a week.

>
Frankly, I don't even see how it would be possible to solve this problem.
How do you want to distinguish between the exceptions you want to stop at,
and the exceptions you don't want to stop at?
--

In fact my question is very simple :
Is there a way to halt on all exceptions that are raised directly in my code
even if they are in a try catch :
Ex :
try
connection.open '===I want to stop here if an exception is raised but i
don't want before the 3 previous runtimes exception that are catched and
reraised before in the runtime code.
catch ex
end try

John Saunders [MVP]

[Steven Cheng[MSFT]]

Thanks for your followup Olivier,

I can understand your concerns here that you want to make sure your
application services 100% secure and stable. I think John just want to mean
that normally for those exceptions that have been catched the runtime
framework, the framework should has been taken care of them and we do not
need to deal with them directly. Our .net framework application should
focus on any unhandled exceptions in our application scope. If you do need
to capture all the exceptions (no matter first chance or second chance), I
think it should be more like the jobs of a debugging tools rather than
application service. For such scenario, you can try looking for some
reference about debugging API (most of them are unmanaged interface as I
know).

Anyway, within the managed application's process itself(other than another
debuger process), I don't think it is quite supported to do so.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.