I currently have some code that delibratly throws an exception if the user sends me data that fails validation (see below). I like it because im sure any errors in the application are caught and handled. A am however worried the code being slow as throwing exceptions takes a lot of memory. Im also worried it might be "bad code". Whats your advice? Thanks
public class BTAmendAppointmentRequest
{
public DataLayer.WebserviceMessage AddBTAmendAppointmentRequest(DataLayer.BTAmendAppointmentRequest req)
{
DataLayer.WebserviceMessage rsp = new DataLayer.WebserviceMessage();
try
{
if (!String.IsNullOrEmpty(req.AppointmentReference))
req.AppointmentReference = req.AppointmentReference.Trim();
if (req.OrderRequestID < 1 || string.IsNullOrEmpty(req.AppointmentReference))
{
throw new Exception("Amend appointment failed, you must supply a valid appointment reference and order reference");
}
...Do other stuff
}
catch (Exception ex)
{
rsp = new Service.WebserviceErrorMessage(ex);
}
return rsp;
}
}
If you are expecting these errors, you should return error messages to the user, not throw exceptions.
Reserve exceptions to exceptional situations.
Apart from being expensive, the meaning of an exception, the semantics are that of something exceptional having happened. Validation failing is not exceptional, it is expected.
Having said that, seeing as you are on a web service, an exception is a reasonable thing to do, assuming you also validate before the service call. It is reasonable since a web service can be called by anything - validation may not have happened, and such errors should be exceptional. Additionally, at least with .NET web services, web exceptions are probably the best way to communicate such things back to the client.
Exceptions should be considered as last resort error trap. They should be "exceptional". Data input errors are not exceptions - they are very common, expected events. You shoudl handle validation issues with validation controls or processes, that handle them - display an error message and do not let the processing continue.
Your other problem is that you cannot easily do full form validation if the first error you encounter throws an exception. If I was filling out a form where each error was separately highlighted, I would give up very quickly. You need to be able to validate and display ALL errors on a page, and not permit progress without validation succeeding.
I tend to agree with Oded in that exceptions should only be used for stuff you aren't expecting. The other way to look at it is with using an errors collection, you are able to validate a larger batch instead of throwing an exception on the first problem. This can be more usable for the person consuming your service.
In the case of web services, I would package the entire response in a custom response object, which features a return code. This allows you to have a return code of error, and then encapsulate an errors collection in the response object.
Related
I don't like error handling via try catch blocks but in this case I did not see any other clear path. In my code I'm calling a web service but it might soon be a rest API in the near future. This web service is external and unfortunately not 100% reliable. What I need to do is create code that can handle an unresponsive web service. Today it looks like this:
SOAP Proxy is set to have a timeout of 120 seconds
var myProxy = new WebReference.ProxyClass();
myProxy.Timeout = 120000;
try
{
CreditInformation creditInformation = myProxy.Retrieve(prospect.CorporateIdentity);
agreement.Company.Name = creditInformation.CompanyName;
agreement.FinancialInformation.NetRevenue = creditInformation.Revenue / 1000;
}
catch (WebException e) when (e.Status == WebExceptionStatus.Timeout)
{
logger.Error("Web service timed out");
}
//Continiue running code even if the web service time out
Is this a bad standard and could it be better performed? As I said before I don't like handling errors via try catch but it seemed viable here. I thought about creating some code to check if the web service was responding but i decided not to go this way. This is because the web service is quite slow, a request takes 30-60 seconds by default and that would leave the user waiting even longer for me to check if it is up. Another solution might be to ping the host but it does not guarantee that the service is actually up. Sample code:
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
if (response != null && response.StatusCode == HttpStatusCode.OK)
{
//Do stuff here
}
There are two opposite camps about how to handle exceptional situations. One camp prefers exceptions, another camp prefers to return error codes (or similar) from a function that might fail in one form or another. What is "better" is arguable and situation-dependent (see for example: http://www.joelonsoftware.com/items/2003/10/13.html for the arguments of "error code" camp). I'm telling this because as I understand you would prefer that myProxy.Retrieve return some error code on timeout, not throwing an exception. It might be reasonable, but that's not how it works and you cannot change that. Whole .NET framework uses exceptions almost everywhere (sometimes in situations which might be considered "part of normal flow", though definition of normal flow is again not trivial).
Long story short - a lot of code you use in .NET will throw exceptions on errors, even in sutations which you consider normal, and you have to live with that and act accordingly - catch and handle them - that's perfectly normal. Usually there are 2 points against exceptions:
They cost some time and resources to construct, as you mention in comment. That's reasonable concern in some code which executes thousands of operations per second, and those operations throw thousands of exceptions. In your case however, request takes 30-60 seconds, and as such cost of exception is absolutely zero compared to that.
They change control flow, sometimes moving it very far from actual exception source (like goto statement). To handle this (if you are in the "error code" camp, but have to work with exceptions anyway), you should put try-catch block as close as possible to the function which produces it, and handle exception immedatly, because you know exactly where and why it happened. This if what you already do in your example.
So, surrounding soap service call with try-catch block and handling timeout exception is the best way to go here, and there is absolutely no need to try to avoid this exception being thrown. You might want to not throw exceptions in "normal" conditions yourself, in your own code, but if that happens in third party code - you have to handle and not avoid them.
I do realise that this is not the normal way of doing things, so I will explain a little first before asking the full question.
We are connecting to an external restful service which has 8 methods that we use. It returns a BaseResponse with a:
ResponseCode
ResponseDesc
Message
If the response code is -1 the operation was successful if not the code can be any one of about +-40 errors. To alleviate having a massive switch statement in each processor, I created a ResponseCodeHandler which lives in the project for the external service.
This handler interprets the code and throws the relevant fault with the message as follows:
throw new FaultException<OfflineFault>(new OfflineFault(), errorMessage);
Now since it seems* that almost every error can occur on every method I want to avoid having 40 catches in each processor - almost every error will need to be handled differently and I might as well have switch everywhere. I also can't just rethrow the error since certain items need to be set if a fault is thrown.
I would like to know if something like the following is possible (Where I need to find the OfflineFault in the catch):
try
{
throw new FaultException<OfflineFault>(new OfflineFault(), "description");
}
catch (FaultException e)
{
audit.SetStatus(AuditTransactionStatus.Error, e.Message);
throw faultsource.Build<OfflineFault>();
}
The faultsource just ensures that the error is logged everywhere etc.
I realise I could pass the audit and faultsource through but I would prefer not to since it would be a bit hacky in the current setup.
*Still awaiting feedback from external company
EDIT: Example of catch all as requested. I created an enum for all the codes to aid readability.
// all errors which must throw a offline fault
case ResponseCodes.HostUnavailable:
case ResponseCodes.HostTimeout:
throw faultSource.Build<OfflineFault>(operationName, errorMessage);
// Already registered faults
case ResponseCodes.UsernameAlreadyRegistered:
throw faultSource.Build<UsernameAlreadyRegisteredFault>(operationName, errorMessage);
case ResponseCodes.CellNumberAlreadyRegistered:
throw faultSource.Build<CellNumberAlreadyRegisteredFault>(operationName, errorMessage, ServiceFaultCode.CellNumber);
case ResponseCodes.EmailAlreadyRegistered:
throw faultSource.Build<EmailAlreadyRegisteredFault>(operationName, errorMessage, ServiceFaultCode.Email);
From everything I could find the above is NOT possible.
If you catch the base exception you cannot retrieve the original exception type.
i.e. If you catch Exception you won't be able to find out that it was thrown as a OfflineFault.
I have a program that calls an external web service, and I want to present the user with a friendly dialog if e.g. the server is down, someone cut the cable etc. Assuming the following code
try {
client.MyWebService()
}
catch(? ex)
{
// display friendly dialog explaining what went wrong
}
what exception(s) should I put in place of the question mark in the code? It is kind of hard to actually test situations like this when everything is working smoothly and I have no control over the external part, so some insight would be appreciated.
Thanks!
The first thing to do is take advantage of the .Faulted event on your proxy, which you can wire up like this:
((ICommunicationObject)client).Faulted += new EventHandler(client_Faulted);
In your client_Faulted event handler you can then try re-connecting, or shifting to a backup server, or disabling the UI, logging the error, or displaying a message there.
It's obviously still good practice to wrap each call in a try-catch as well, but the .Faulted event can let you deal with most channel problems even earlier.
As for the exception itself, you can have your service throw a FaultException that gets passed back to the client with the details you provide. See an example of its use at this blog posting.
You won't get a FaultException if the channel itself fails (FaultException is a way for the server to communicate its own internal faults to the client).
For channel faults, you may get a CommunicationException or TimeoutException.
Finally, take a look at this project on Codeplex for generating Exception Handling WCF proxies. It may give you a more flexible way of handing faults.
It's not really the client's job to provide as much detail as possible. The maximum amount you really have to provide at the client side is as much as you get back in your exception.
var userName = "bob";
try
{
client.MyWebService(userName);
}
catch(Exception ex)
{
//Maybe we know WellKnownExceptions and can provide Foo advice:
if (ex is WellKnownException)
{
Console.WriteLine("WellKnownException encountered, do Foo to fix Bar.");
}
//otherwise, this is the best you can do:
Console.WriteLine(string.Format(
"MyWebService call failed for {0}. Details: {1}", userName, ex));
}
I was asking the same question, as I have to implement some exception handling on web services calls at my client application, so I ended up here. Although it's an old question, I'd like to give my two cents, updating it a little bit.
The answer given by C. Lawrence Wenham was already very good and points to some interesting information, although the blog link is broken and Codeplex is now archived.
I found those articles very valuables:
Sending and Receiving Faults
https://learn.microsoft.com/en-us/dotnet/framework/wcf/sending-and-receiving-faults
Expected Exceptions
https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/expected-exceptions
And this article from Michèle Leroux Bustamante (apparently the creator of the Exception Handling WCF Proxy Generator CodePlex project) is very insighful also:
An Elegant Exception-Handling Proxy Solution
http://www.itprotoday.com/microsoft-visual-studio/elegant-exception-handling-proxy-solution
I'm still studying the subject but I guess I'll use a lot of ideias from Michèle. I'm just a little bit concerned about using reflection to call the web service's methods, but I wonder if this would have any impact in such kind of operation, that is inherently slow already.
Just to answer here explicitly what was asked originally, which are the exceptions that could be tested against a web service call:
string errorMessage = null;
// A class derived from System.ServiceModel.ClientBase.
MyWebService wcfClient = new MyWebService();
try
{
wcfClient.Open();
wcfClient.MyWebServiceMethod();
}
catch (TimeoutException timeEx)
{
// The service operation timed out.
errorMessage = timeEx.Message;
}
catch (FaultException<ExceptionDetail> declaredFaultEx)
{
// An error on the service, transmitted via declared SOAP
// fault (specified in the contract for an operation).
errorMessage = declaredFaultEx.Detail.Message;
}
catch (FaultException unknownFaultEx)
{
// An error on the service, transmitted via undeclared SOAP
// fault (not specified in the contract for an operation).
errorMessage = unknownFaultEx.Message;
}
catch (CommunicationException commEx)
{
// A communication error in either the service or client application.
errorMessage = commEx.Message;
}
finally
{
if (wcfClient.State == CommunicationState.Faulted)
wcfClient.Abort();
else
wcfClient.Close();
}
As stated by the articles, the order the exceptions are catched is important, since FaultException<TDetail> derives from FaultException, and FaultException derives from CommunicationException.
I am calling a web service from a C# forms based app.
ServReturnType obj = ServProxyClass(int i, int k);
I have the potential to get back an exception. The exception could be that the service didn't connect at all, that there was a failure on the receive, but the original message went, or anything in between. I then need to make a decision based on the exception thrown, either on the type, or the message, or both, as to do one of two actions next.
try
{
ServReturnType obj = ServProxyClass(int i, int k);
}
catch (WebException ex)
{
DoAction1();
}
catch(SocketException ex)
{
DoAction2();
}
catch(SoapException ex)
{
DoAction1()
}
The issues is, my choice of subsequent actions depends on whether or not the first call made it to the server before failing. How can I find a list of all possible exceptions thrown, and what they might mean, as this is all code in the framework. I looked that MSDN docs, and saw that SoapHttpClientProtocol.Invoke can throw a SoapException, however there are methods called by this method that bubble up System.Net.WebExceptions. So I need a list of the whole call stack and what it can throw, and what that means.
Any ideas?
Update 1
Darin, your answer more or less confirms my suspicions that what I want doesn't really make sense. I have opted to do more detective work first, then use that to decide what to do next. Unfortunately in this case, since we are processing credit cards, it really matters what exactly has happened, and whether or not we sent data.
The complete list of exceptions that can be thrown from a web service call is so vast that I really don't think that it is a good idea to test for every type of exception possible. In many cases it would be enough to catch for SoapException which could contain some business errors transmitted through the SOAP Fault Element and every other exception could be considered as a non handled error:
try
{
ServReturnType obj = ServProxyClass(int i, int k);
}
catch(SoapException ex)
{
//Serialize and analyze the fault message from the exception to obtain more info.
DoSomethingWithTheInfo();
}
catch(Exception ex)
{
LogTheExceptionSoThatLaterYouKnowWhatHappened(ex);
SayToTheUserThatSomethingTerriblyWrongHappened();
}
Here's a nice article explaining how to raise and handle SoapExceptions.
I have a website built in C#.NET that tends to produce a fairly steady stream of SQL timeouts from various user controls and I want to easily pop some code in to catch all unhandled exceptions and send them to something that can log them and display a friendly message to the user.
How do I, through minimal effort, catch all unhandled exceptions?
this question seems to say it's impossible, but that doesn't make sense to me (and it's about .NET 1.1 in windows apps):
All unhandled exceptions finally passed through Application_Error in global.asax. So, to give general exception message or do logging operations, see Application_Error.
If you need to catch exeptions in all threads the best aproach is to implement UnhandledExceptionModule and add it to you application look here
for an example
Use the Application_Error method in your Global.asax file. Inside your Application_Error method implementation call Server.GetLastError(), log the details of the exception returned by Server.GetLastError() however you wish.
e.g.
void Application_Error(object sender, EventArgs e)
{
// Code that runs when an unhandled error occurs
log4net.ILog log = log4net.LogManager.GetLogger(typeof(object));
using (log4net.NDC.Push(this.User.Identity.Name))
{
log.Fatal("Unhandled Exception", Server.GetLastError());
}
}
Don't pay too much attention to the log4net stuff, Server.GetLastError() is the most useful bit, log the details however you prefer.
The ELMAH project sounds worth a try, its list of features include:
ELMAH (Error Logging Modules and
Handlers) is an application-wide error
logging facility that is completely
pluggable. It can be dynamically added
to a running ASP.NET web application,
or even all ASP.NET web applications
on a machine, without any need for
re-compilation or re-deployment.
Logging of nearly all unhandled exceptions.
A web page to remotely view the entire log of recoded exceptions.
A web page to remotely view the full details of any one logged
exception.
In many cases, you can review the original yellow screen of death that
ASP.NET generated for a given
exception, even with customErrors mode
turned off.
An e-mail notification of each error at the time it occurs.
An RSS feed of the last 15 errors from the log.
A number of backing storage implementations for the log
More on using ELMAH from dotnetslackers
You can subscribe to the AppDomain.CurrentDomain.UnhandledException event.
It's probably important to note that you are not supposed to catch unhandled exceptions. If you are having SQL timeout issues, you should specifically catch those.
Do you mean handling it in all threads, including ones created by third-party code? Within "known" threads just catch Exception at the top of the stack.
I'd recommend looking at log4net and seeing if that's suitable for the logging part of the question.
If using .net 2.0 framework, I use the built in Health Monitoring services. There's a nice article describing this method here: https://web.archive.org/web/20210305134220/https://aspnet.4guysfromrolla.com/articles/031407-1.aspx
If you're stuck with the 1.0 framework, I would use ELMAH:
http://msdn.microsoft.com/en-us/library/aa479332.aspx
hope this helps
There are 2 parts to this problem handling & identifying.
Identifying
This is what you do when the exception is finally caught, not necessarily where it is thrown. So the exception at that stage must have enough context information for you to idenitfy what the problem was
Handling
For handling, you can
a) add a HttpModeule. See
http://www.eggheadcafe.com/articles/20060305.asp
I would suggest this approach only when there is absolutely no context informaatn available and there might be issuus wiih IIS/aspnet, In short for catastrophic situations
b) Create a abstract class called AbstractBasePage which derives from Page class and have all your codebehind classes derive from AbstractBasePage
The AbstractBasePage can implement that Page.Error delegate so that all exceptions which percolate up through the n-tier architecture can be caught here(and possibly logged)
I would suggest this cause for the kind of exceptions you are talking about (SQlException) there is enough context information for you to identify that it was a timeout and take possible action. This action might include redirecting user to a custom error page with appropriate message for each different kind of exception (Sql, webservice, async call timeouts etc).
Thanks
RVZ
One short answer is to use (Anonymous) delegate methods with common handling code when the delegate is invoked.
Background: If you have targeted the weak points, or have some boilerplate error handling code you need to universally apply to a particular class of problem, and you don't want to write the same try..catch for every invocation location, (such as updating a specific control on every page, etc).
Case study: A pain point is web forms and saving data to the database. We have a control that displays the saved status to the user, and we wanted to have common error handling code as well as common display without copy-pasting-reuse in every page. Also, each page did it's own thing in it's own way, so the only really common part of the code was the error handling and display.
Now, before being slammed, this is no replacement for a data-access layer and data access code. That's all still assumed to exist, good n-tier separation, etc. This code is UI-layer specific to allow us to write clean UI code and not repeat ourselves. We're big believers in not quashing exceptions, but certain exceptions shouldn't necessitate the user getting a generic error page and losing their work. There will be sql timeouts, servers go down, deadlocks, etc.
A Solution: The way we did it was to pass an anonymous delegate to a method on a custom control and essentially inject the try block using anonymous delegates.
// normal form code.
private void Save()
{
// you can do stuff before and after. normal scoping rules apply
saveControl.InvokeSave(
delegate
{
// everywhere the save control is used, this code is different
// but the class of errors and the stage we are catching them at
// is the same
DataContext.SomeStoredProcedure();
DataContext.SomeOtherStoredProcedure();
DataContext.SubmitChanges();
});
}
The SaveControl itself has the method like:
public delegate void SaveControlDelegate();
public void InvokeSave(SaveControlDelegate saveControlDelegate)
{
// I've changed the code from our code.
// You'll have to make up your own logic.
// this just gives an idea of common handling.
retryButton.Visible = false;
try
{
saveControlDelegate.Invoke();
}
catch (SqlTimeoutException ex)
{
// perform other logic here.
statusLabel.Text = "The server took too long to respond.";
retryButton.Visible = true;
LogSqlTimeoutOnSave(ex);
}
// catch other exceptions as necessary. i.e.
// detect deadlocks
catch (Exception ex)
{
statusLabel.Text = "An unknown Error occurred";
LogGenericExceptionOnSave(ex);
}
SetSavedStatus();
}
There are other ways to achieve this (e.g. common base class, intefaces), but in our case this had the best fit.
This isn't a replacement to a great tool such as Elmah for logging all unhandled exceptions. This is a targeted approach to handling certain exceptions in a standard manner.
Timeout errors typically occur if you are not forcefully closing your sqlconnections.
so if you had a
try {
conn.Open();
cmd.ExecuteReader();
conn.Close();
} catch (SqlException ex) {
//do whatever
}
If anything goes wrong with that ExecuteReader your connection will not be closed. Always add a finally block.
try {
conn.Open();
cmd.ExecuteReader();
conn.Close();
} catch (SqlException ex) {
//do whatever
} finally {
if(conn.State != ConnectionState.Closed)
conn.Close();
}
This is old question, but the best method (for me) is not listed here. So here we are:
ExceptionFilterAttribute is nice and easy solution for me. Source: http://weblogs.asp.net/fredriknormen/asp-net-web-api-exception-handling.
public class ExceptionHandlingAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
var exception = context.Exception;
if(exception is SqlTimeoutException)
{
//do some handling for this type of exception
}
}
}
And attach it to f.e. HomeController:
[ExceptionHandling]
public class HomeController: Controller
{
}