Develop Reference

Retrieve unique error code from any type of exception

I have code in my application which uses system libraries that can throw a CryptographicException.
In my case these exceptions can occur when
password for a ssl certificate is malformed
password for a ssl certificate is in plain text
but this shouldn't matter since my question is pretty general.
So for the first case the exception that is thrown is
System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
And for the second case the exception that is thronw is
System.Security.Cryptography.CryptographicException: The input data is not a complete block.
So what I want to do is to log this error into the Windows Event Log and I want to use different event ids based on the error.
So for example, the first error that is thrown shall be logged with event id 1 and the second one with event id 2.
Also, I don't want to use Exception.Message to log into the event log since the errors don't show that it's based on the password. I, as a developer, of course know where it's coming from, but when a system administrator checks the logs he won't have any idea what this means. It could mean anything.
However, I looked at the exceptions, and other than the message/stack trace there is no difference between these exceptions.
I saw that there is a HResult attribute which identifies the excpetion, however when I use e.HResult.ToString("x") it is 80131501 in both cases (input data not being a complete block and padding being invalid)
So I don't want to use a string comparison to see which event id to throw and which message to use. Is there any other besides the message string to identify which exact message has been thrown?
From other languages, I know that exceptions often have an ErrorCode attribute which is unique to the exception AND the message.
Is there something similar in C# or how would I identify two different exception messages from the same exception class?

What's causing this exception?

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.

HttpRequestException vs WebException

This is a general question that I'm confused about. I thought once a REST request was made, an error would come back via a WebException. In one case I have I'm getting a HttpRequestException, which doesn't allow me to get the HTTP status code.
I'm new to this stuff, but what is the difference between these? Why are there two types? When does one get used as opposed to another?
WebException seems to work well. HttpRequestException seems like a very weak version of it, where it knows the status code (in it's message) but it won't tell me explicitly what it was.
EDIT:
I'm using a HttpClient. Specifically calling client.GetStreamAsync().

There are three distinct failure scenarios:
a) You could not connect to the server or proxy, in which case a HttpRequestException is thrown. Be aware if your server is down and you are running fiddler, you will never see this exception, you will get a 5XX status code.
b) When reading/writing a network stream, there is some kind of interruption you will get an IOException.
c) You will get back a response with a HttpStatusCode with a 4XX/5XX status code. If your client application chooses to call response.EnsureSuccessStatusCode() then a HttpRequestException will be thrown.
If you decide to call EnsureSuccessStatusCode you are making an explicit decision that you don't care about status codes other than the fact that it was success/fail.
If you really need to bubble up an exception and then later handle the status code then I suggest you create your own extension method to replace EnsureSuccessStatusCode and create your own exception that can store the status code. Or preferably, translate the status code into one of a few different exceptions based on the corrective action you wish to take.

WebException Class: The exception that is thrown when an error occurs while accessing the network through a pluggable protocol.
HttpRequestException Class: A base class for exceptions thrown by the HttpClient and HttpMessageHandler classes.
I think the inner exception of a HttpRequestException could be a WebException however I'm not sure it ever is.
Note, a 404, 302 or whatever response other than a 200 (OK) is not an exception. Those responses are perfectly valid HTTP responses.

https://github.com/dotnet/runtime/pull/32455 adds StatusCode to HttpRequestException in .NET 5.

Best practice to handle WCF service errors?

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.

Is it Ok to throw exceptions back to a client from my service?

I am writing a Java based service with WSDL for a .Net client to consume, and I thought that when I receive an invalid value from the client that I would throw an exception that my client could then catch and display in a message box or something to the user (the client is a desktop app).
I was wondering if it would be ok to use this approach or if there's a better way of doing it.

I would say "no". Error messages, etc., but I wouldn't serialize an exception. You have no idea who the client is or what language they're written in.
The service should handle the exception: catch it, log it, and create a sensible error message(s) and status codes. This is not the place for exceptions, in my opinion.
And when I say "sensible error messages", I don't mean anything resembling a stack trace. These are likely to be business clients, who should not be reading such things. A business-meaningful message is the ticket here, not a stack trace.

.NET in general deals in FaultExceptions (wrapped SOAP faults) in WCF. I would assume that if you throw a proper SOAP Fault, that WCF would wrap this up into a FaultException by the time the client consumes the response, so they can have a try catch FaultException statement. This would still allow other non .NET clients to consume the service without breaking standards..
Just an idea anyway...

What you should probably do is use SOAP Faults, since these should be supported for any clients. Be sure to set the extra descriptive fields too.

Conceptually this is fine, but I don't think you can literally throw a Java Exception over HTTP back to a .NET client.
You can use HTTP 500 to signal a server error; you should also be able to attach a meaningful message to the response that will help the .NET developers figure out how to use your service better. This may or may not include a serialized Java stack trace.

The first thing to tackle is preventing against exceptions being thrown by doing validation on data before it gets manipulated. IE
string func(string cat)
if(cat == null || cat.length == 0){
//set errorLabelText to "bad data"
return;
}
//else code
That being said only throw Exceptions in Exceptional cases.