How to avoid first time exceptions when calling a webmethod ? -- dotnet web services

dotnet web services : How to avoid first time exceptions when calling a webmethod ?

John Saunders [MVP]
7/30/2007 4:05:19 PM

[quoted text, click to view]

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]

John Saunders [MVP]
7/30/2007 5:55:31 PM

[quoted text, click to view]

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]

Olivier BESSON
7/30/2007 9:44:35 PM

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

Olivier BESSON
7/30/2007 11:40:17 PM

"John Saunders [MVP]" <john.saunders at trizetto.com> a écrit dans le
message de news: eEcd2Tu0HHA.3848@TK2MSFTNGP03.phx.gbl...
[quoted text, click to view]

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

stcheng NO[at]SPAM online.microsoft.com
7/31/2007 12:00:00 AM

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

Olivier BESSON
7/31/2007 12:00:00 AM

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]" <stcheng@online.microsoft.com> a écrit dans le message
de news: 3jlXN7z0HHA.4844@TK2MSFTNGHUB02.phx.gbl...
[quoted text, click to view]

John Saunders [MVP]
7/31/2007 1:15:43 PM

[quoted text, click to view]

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]

John Saunders [MVP]
8/2/2007 10:59:19 AM

[quoted text, click to view]

Why do you think there's a lot of reflection being used?

[quoted text, click to view]

This is not an exception. It's part of the HTTP protocol and is part of
normal processing.

[quoted text, click to view]

No, you won't. Why do you think there would be an exception? Also, you would
only see the exception if it was unhandled by the runtime. In that case, you
should do what I suggested and get rid of the "stop when thrown" checkbox.

[quoted text, click to view]

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.

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.

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?
--
John Saunders [MVP]

Olivier BESSON
8/2/2007 1:49:13 PM

"John Saunders [MVP]" <john.saunders at trizetto.com> a écrit dans le
message de news: u3BduZ50HHA.1336@TK2MSFTNGP04.phx.gbl...
[quoted text, click to view]

Ok, thanks for the response.
When i sayed "hidden" i wanted to say what you say.
I think i can best explain what i want to do (if possible ???) with an
example :

I suppose that when you build a web service (client or server) there is a
lot of inheritance and a lot of code that use reflexion to get information.
Maybe for example with the client :
Client opens a tcp connection with the server
Client use the tcp to do a post in anonymous mod
If there is an exception that say "authent = windows" Client catchs it
Client use the tcp to do a post in with NTML auth
If ok Client return ok
Else Client return new exception(not authentified)
Else Client return ok

In this case i'll always have an exception if server is in "authent =
windows".
What i wanted was :
Is there a way to have access to all these code (auto generated base
sources, delegates on certains objects, ohter ???) to tell it not to try
anonymous because i know i must use NTLM ?
OrElse is there a documentation on how to "make from scratch" a web service
client using the xsd generated code only for the soap serial/deserial.

If i insist so it's because i have one of my most important "best practices"
from years that is :
In a normal conditions if your code is correct you must have NO exceptions
and one of the first rules for me and my team is :
Do all your coding and tests in debug mode with halt on all exceptions (vb6
and vb.net) : you must never halt, only from real exceptions (network
failure, no more space on hd, etc ...).
The ErrorHandlers or Try Catches are here only to prevent opened resources
and application crach if bad things appears, if you use carefully objects
and properties you can have no exceptions.

So theses runtime exceptions makes my life very hard to debug code because
you always have to click on prompt and not looking carefully at message i
can click continue not seeing the exception comes from my code and so
loosing the ability to modify source to prevent it (not sure you will
anderstood this phrase because it's very hard to explain it in english).

Thanks for your response

Regards,

Olivier

Olivier BESSON
8/9/2007 6:51:55 PM

[quoted text, click to view]

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

[quoted text, click to view]

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.

[quoted text, click to view]

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

[quoted text, click to view]

stcheng NO[at]SPAM online.microsoft.com
8/10/2007 12:00:00 AM

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

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet web services

home · blog · groups

Questions? Comments? Contact the dn