What's wrong with this? I get the exception
An unhandled exception of type 'System.Net.WebException' occurred in System.dll
Additional information: An exception occurred during a WebClient request."
Here's the part of the code with the WebClient.
I need to learn how to use the code part properly one day....
http://pastebin.com/1Z90bvqB
Any answers are greatly appreciated.
(I'm not sure I agree with the ethics of the code itself, but ignoring that...) a WebException is caused by a line that connects to the internet, so either one of the lines like:
webClient.DownloadFile(String.Copy(WeepCraft), #"%appdata%\.minecraft\versions");
Or the line:
Process.Start("http://www.wirez.cf/");
In the latter case, unless I'm misunderstanding, is this actually a process you can start??
Anyway, around all the lines, you'll need to have a try/catch for WebException in case it can't connect for whatever reason (eg Internet down, wrong URL used, server returns HTTP Error code etc etc), and decide how to handle it.
It's a pretty common Exception whenever something tries to do a http request and the server can't be connected to for whatever reason.
Related
I 'm looking for a similar library or class like httpwebrequest which does not throw exceptions on http codes. (c# language)
Problem with httpwebrequest is that it behaves the http error codes (like 401,403 and ...) as exceptions and throws an exception in case of these. You may know that exception throwing and handling is expensive. for example a successful request takes about 30 ms on my system,but another request which causes exception takes about 250!
I 'm making lots of request that causes this http error codes and it affects my code performance alot.
I have tried webclient,webrequest,httpclient and all are the same in this.
Any opinion on a alternative library or how to avoid these exceptions ?
HttpClient.GetAsync() won't throw an exception on a 400-level error. Though it will throw an exception for "an underlying issue such as network connectivity, DNS failure, server certificate validation or timeout."
Also, the HttpReponseMessage it produces has a handy IsSuccessStatusCode property.
Check out RestSharp. It's a great tool for creating web requests
I am coding some kind of a WCF service. most exceptions are caught in the BL implementation and handled there. Each of my API's return type is a class (named - "result") containing error code, error message and success boolean.
When exceptions are handled, this class is updated accordingly and in the end is sent back to the client.
Some of the exceptions are off-course, unhandled. Currently, I am wrapping each of my BL calls from the service layer with a generic try-catch so I can catch every unhandled exception and create a generic "result" class with a generic failure message, error code and success=false.
Is it a good way to handle exceptions or should I let unhandled exception to be thrown by the service to the client?
You can assume that the client can't use the data from the exception so it won't benefit from the extra information contained in the exception.
Check out Exception Shielding.
This is a process where exceptions raised by the service, are mapped to fault contracts according to rules you specify in a configuration file. This saves a lot of donkey work with try/catch blocks.
Here is one post to help you out:
In general though - faults will fall into 3 categories:
1) Client error - the client has tried to do something not permissable, so it needs to know about it. E.g. Failed to set a mandatory field. - Return specific message explaining fault.
2) Business error that doesn't affect the client. An error that is considered normal operation, e.g. Payment Authorization check failure. Either hide from client completely, or return some message: "Error performing request: Please try again later..."
3) System error - Unexpected - not normal operation: Replace with generic message: "System Error: Call Support"
In all cases though, the key thing is you remove the stack trace, especially if it's a public facing service.
With shielding you would have 3 Fault Contracts covering the above scenarios, and set the text appropriately in the Shielding configuration.
Be advised, you generally want shielding turned off during development as it makes it a right pain to debug the system!
I differ with the others. I think that in the same way HTTP methods GET, POST, PUT, DELETE thereby support CRUD operations, HTTP response codes 200, 500, etc., support success/fail and this is, in my opinion, appropriate to make use of. A 500 result still has an HTTP response body, and such a body is fully readable (so long as IIS isn't spitting out HTML; you have control over this). Meanwhile, the XML protocol implementations as with Microsoft SOAP from WCF already wrap exceptions with a faulting protocol.
If you're going to throw exceptions, throw them. Just document them while doing so, so that the consumers can plan accordingly.
I think both approaches are viable.
I personally prefer not throwing exceptions over WCF, so that the client can easily distinguish between error in server-side processing and connectivity/protocol issue: in the first case the response will indicate the failure, and in the second case exception will be thrown.
Personally I wouldn't expose the unhandled exceptions and propagate them to the client. I would define those exceptions the client might be interested in and only propagate those. Exceptions not directly related to what the clients want to do (ArgumentException could set reason to "CustomerId cannot be more than 20 chars" etc.) I'd deal with in the service and only indicate that some sort of internal server error has occurred on the service side which broke the execution and meant that the operation the client tried to run failed to complete. This I would do because the client can't really take any action based on internal server errors. They can fix their inparams in the case of an ArgumentException being thrown by validating the parameters again and retry the operation.
Not sure if this is really what you're asking, but hope it gives you some ideas at least.
If you let unhandled exceptions out of your WCF service, this may have undesirable effects such as communication channel being in faulted state where in a sessionful scenario, client can no longer use the same client proxy instance but is forced to create a new one and start a new session. In general, I think it is good to have control over the errors that surface out of your WCF service and provide clients helpful information. Take a look at IErrorHandler.This interface gives you control over the SOAP fault generated, unhandled exceptions, and allows you to do extra tasks like logging, and lets you decide whether you want to keep the session or not in case of a sessionful binding. You add your custom error handler via WCF extensibility such as service, endpoint, contract, operation behaviors.
Note that IErrorHandler is called before sending a response message. So there is still a chance of an unhandled exception occurring down in the channel stack during serialization, encoding, etc.
When I start my application (it is a client which connect with WCF to a Service) I see in the Output-Window of Visual Studio many lines with
A first chance exception of type 'System.Xml.XmlException' occurred in System.Xml.dll
I have turn on the throw of this Exception and see, that it occures, when the client calls the WCF-Service. The Message of the Exception is:
A name must not beginn with '<'
(in german: Ein Name darf nicht mit dem Zeichen '<', hexadezimaler Wert 0x3C, beginnen.)
Should I do something about this? Or is this normal? Can this be a performance issue?
Thanks for your help.
Best Regards, Thomas
I also got this exception after calling my wcf dataservic endpoint a couple of times. After some searching i found this post that was spot on:
https://social.msdn.microsoft.com/Forums/en-US/74813783-8666-40c4-a9fd-7953f7b6849c/invalid-xml-with-two-feed-elements-returned-after-a-few-requests?forum=adodotnetdataservices
When you have WCF tracing configured and you have set
logMessagesAtTransportLevel to true, you get this behavior
So i changed the configuration of my service and it worked.
This is normal. First chance exception messages indicate exceptions that were thrown and handled.
The ones you are getting is probably due to missing configuration info or serialization info in your assembly. The aforementioned might not be needed if everything is working fine.
9 changes out of 10 this is not a problem. It's common in those classes (and also in, e.g. Entity Framework) to throw exceptions when it's run. So I wouldn't worry about it too much.
I would worry if you can step into the code (i.e. you wrote the code yourself that throws the exception).
But I don't think that is the case.
If an exception is thrown in my web service and I wanted to give the user a more meaningful error message rather than a generic 'an error has occurred when processing your request', what are some possible techniques that can be used to pass the exception message back to the client?
is this something that is acceptably practiced?
If the error is from your inner code .NET will wrap your inner exception in a SoapException and return it to the user. The JavaScript can look for the soapexception xml element and do something with it. The SoapExceptions message will be the same as the actual exception so you might want to catch it up top and throw something nicer, and without the stack trace.
You can then give the clients a list of possible SoapExceptions.
I've written web services where the response always includes a numeric status code (0 indicates success, non-zero indicates a problem of some type) as well as a text status message. If an error occurred (non-zero status code) then the status message includes a description of the problem, otherwise it is blank. The service also returns a bunch of data depending on what method the user is calling. It seems to work well for our clients. The important thing is to document the behavior so that clients know what to expect and the interface is consistent.
this is probably the most helpful answer to this question
What should a JSON service return on failure / error
so, thanks to Crescent Fresh
Here is the complete error message:
An exception of type
'System.Web.HttpException' occurred in
System.Web.dll but was not handled in
user code
Additional information: The remote
host closed the connection. The error
code is 0x80070057.
and the offending code:
char[] buffer = oPage.HTML.HTML.ToCharArray();
Page.Response.Write(buffer, 0, buffer.Length);
Page.Response.Flush();
Page.Response.End();
The oPage.HTML.HTML is a string in a custom page object used by our app. The exception triggers on Page.Flush() and appears to be benign -- I just hit "continue" and everything goes along fine. This never appears at run time.
I have chased many, many Google hits down many rabbit holes and have found nothing. Visual Studio 2005, Vista Ultimate (IIS7).
I've been dealing with this same error for a while now, and my understanding is that when Flush is called, there must be a connection on the other end, otherwise, this error is thrown. It's easy to get into a "fire-and-forget" kind of model when writing web pages, but when the client disconnects (in this debugging case, you're the client), there's nowhere to flush to.
There are two solutions I've found to this:
Wrap Response.Flush and catch the exception.
Check Response.IsClientConnected before you call flush.
I'm not 100% sure about the second one...I'm still in the process of checking that one out.
Good luck!