I am currently in a try catch finding if a property has been set properly to the bool value that it should be like this...
public void RunBusinessRule(MyCustomType customType)
{
try
{
if (customType.CustomBoolProperty == true)
{
DoSomething();
}
else
{
throw new Exception("This is obviously false or possibly null lets throw up an error.");
}
}
catch(Exception)
{
throw;
}
}
Now the deal with throwing this error for me is that I am using Microsoft's source analysis and it gives me an error stating "CA2201 : Microsoft.Usage : Object.RunBusinessRule(MyCustomType)creates an exception of type 'Exception', an exception type that is not sufficiently specific and should never be raised by user code. If this exception instance might be thrown, use a different exception type.
Soooo What exception should I throw that would be specific enough for Microsoft.., for the circumstance of throwing an error about my own application's logic handling and when I want to "throw".
ArgumentException
InvalidOperationException
FormatException
The passed in argument wasn't good.
Create your own exception extending Exception. E.g.: RuleViolationException
Should you be throwing an exception at all?
Having a false boolean value isn't exactly an exceptional circumstance.
EDIT
My original answer was a bit terse so I'll elaborate...
From your example it's not clear what the actual objects, properties and methods represent. Without this information, it's difficult to say what type of exception, if any, is appropriate.
eg, I'd consider the following a perfectly valid use of an exception (and your real code might well look something like this, but we can't tell from your example):
public void UpdateMyCustomType(MyCustomType customType)
{
if (!customType.IsUpdateable)
throw new InvalidOperationException("Object is not updateable.");
// customType is updateable, so let's update it
}
But in the general case, without knowing more about your domain model, I'd say that something like this (a false boolean value) isn't really exceptional.
ArgumentException maybe?
A case could be made for InvalidOperationException, too.
The answer here is that you shouldn't throw any exception. Why throw an exception just to catch it again in a second and rethrow it?
A slight aside, but you could simplify your code somewhat...
public void RunBusinessRule(MyCustomType customType)
{
if (customType.CustomBoolProperty == false)
{
throw new Exception("This is obviously false or possibly null lets throw up an error.");
}
DoSomething();
}
As for the type of exception to throw, you might consider ApplicationException or InvalidOperationException, or you could define your own exception type.
I know that a question is about throwing an exception but I think it would be more appropriate to do an assertation here:
// Precondition: customType.CustomBoolProperty == true
System.Diagnostics.Debug.Assert(customType.CustomBoolProperty)
DoSomething();
InvalidArgument exception is fine but better yet, an ApplicationException.
The other answers are fine for quick resolution, but ideally if you know at compile time that a certain method should never be invoked using certain parameters, you can prevent that from ever happening by inheriting your custom type, instanciating it only when that custom bool is true, and now your method looks like.
public void RunBusinessRule(MyInheritedType inheritedObject)
{
//No need for checks, this is always the right type.
//As a matter of fact, RunBusinessRule might even belong to MyInheritedType.
}
This is the I in SOLID.
I think you should avoid exceptions for code logic.
I suggest to modify your method to return the result of your method as a bool type then you may decide the appropriate way to show an error message to the user at the time of calling the method:
public bool RunBusinessRule(MyCustomType customType)
{
try
{
if (customType.CustomBoolProperty == true)
{
DoSomething();
return true;
}
return false;
}
catch(Exception)
{
throw;
}
}
Make your own custom exception by extending System.Exception and throw that. You can get even crazier and have a whole tree of exception types if you want.
You could just create a custom ValidationException that is only used for your business logic validation. Or you could create a separate validation exception for each type of validation error although that is probably overload.
Not really what you were asking for, but there are plenty of people who have already given answers that I agree with, but you should also avoid only using catch(Exception ex).
It is a much better practice to try to catch the specific Exceptions that are possible first and if need be, catch the generic Expception. eg:
try{
MyMethod(obj);
}catch (NullReferenceException ne){
//do something
}
catch(UnauthorizedAccessException uae){
//do something else
}
catch(System.IO.IOException ioe){
//do something else
}
catch(Exception){
//do something else
}
Related
I'm having a problem specifying the proper return value in a try/catch block.
I'm novice level scripter and have never used generics before.
The error message is:
"An object of type convertible to T is required"
What specifically do I need to return at the end of my try/catch?
private static T LoadData<T>(string filePath)
{
try
{
return JsonUtility.FromJson<T>(File.ReadAllText(filePath));
}
catch(Exception e)
{
// Something went wrong, so lets get information about it.
Debug.Log(e.ToString());
return ?????;
}
}
It really depends on the application behaviour that you want to define. You can have it return a new T() / default (I wouldn't advise this as users cant tell if the operation was successful or not) or you can throw the exception up a level so that it can be handled else where. The whole point of a try catch is to handle unexpected specific behaviour, thus its not a good idea to catch generic exceptions unless you have a generic way of handling it.
When something went wrong we can't just ignore it; if we don't have enough information to make a decision, a best option is to escalate the problem: may be a top level method knows what to do.
So I suggest to rethrow the exception instead of returning any value:
private static T LoadData<T>(string filePath)
{
try
{
return JsonUtility.FromJson<T>(File.ReadAllText(filePath));
}
catch(Exception e)
{
// Something went wrong, so lets get information about it.
Debug.Log(e.ToString());
// let top level method decide what to do:
// 1. Do nothing (just ignore the exception)
// 2. Do something (e.g. change permission) with filePath
// 3. Try load from some other file
// 4. Try load from some other source, say RDBMS
// 5. Use some default value
// 6. Close the application
// 7. ....
throw;
}
}
Please note, that here, within LoadData<T> method we don't know the context, and that's why we can't decide which option from 1..7 is the best one
I'm looking for the appropriate exception to use for each static method in a class library that I have, as all the methods are related.
public static void EnterText(string element, string value, PropertyType elementType)
{
if (PropertiesCollection.Driver == null)
{
throw new InvalidOperationException();
}
if (elementType == PropertyType.Id)
{
PropertiesCollection.Driver.FindElement(By.Id(element)).SendKeys(value);
}
else if (elementType == PropertyType.Name)
{
PropertiesCollection.Driver.FindElement(By.Name(element)).SendKeys(value);
}
else //if elementType does not make sense an argument exception is thrown
{
throw new ArgumentException();
}
}
The problem is if the PropertiesCollection.Driver is not initialized, the method is useless. Therefore, I'd like to throw an exception if it is null when the method is called. The closest thing I have found to what I'm looking for is InvalidOperationException. However MSDN says it is an "exception that is thrown when a method call is invalid for the object's current state". Since it is a static class and thus has no objects, is this an inappropriate exception type? If no, then which exception should be thrown instead?
Also on more of the organizational side of things, should the code snippet that checks if the driver is null be at the top of each method, or is that too redundant? The alternative that I can think of is a helper method called at the beginning of each that checks and throws an exception if need be.
Some people may disagree with me but saying that InvalidOperationException is the wrong exception simply because there's not technically an instance seems like hair-splitting to me. This seems like a perfectly acceptable use of this exception to me.
I suppose you could create a helper function to test for this condition and decide if you should throw the InvalidOperationException but it truthfully doesn't seem all that worthwhile, plus it could, in my opinion, actually decrease the clarity of the code. The check isn't all that much code and, if I'm reading the code, I'd prefer to just see what checks are happening rather than having to dig into another method to figure it out.
I am writing a method (for a service) that returns a specific error code to the client.
Inside this method I am calling various LINQ extension methods. Each one of these extension methods can throw exceptions of 'same' type (say InvalidOperationException), but I need to catch these exceptions individually and return a specific error code. Here is what it looks like now (much simplified version)
public errorCode SomeMethod()
{
try
{
var foo1 = SomeDataSource.Entities1.Single(x=> x.bar1 == somevalue);
}
catch(InvalidOperationException x)
{
return ErrorCode1;
}
try
{
var foo2 = SomeDataSource.Entities2.Single(x=> x.bar2 > somevalue);
}
catch(InvalidOperationException x)
{
return ErrorCode2;
}
......
This is adding up to be a lot of try-catch blocks, as there are several error conditions that can potentially exist. It is also forcing me to elevate the scope of variables like foo to outside the individual try blocks, as they are being used in subsequent try blocks.
I am just curious to see if there is a way to consolidate all this code in a more elegant manner (some inline methods perhaps?) so that it doesn't end up looking so intimidating?
Based on the feed back I got, I have to add that the Business Rules that I am trying to implement leads me to use 'Single' and not 'SingleOrDefault'. Using 'SingleOrDefault' makes it easier because then we can just check for null without catching the exception. 'Single' on the other hand simply throws an exception if the condition fails. Idea here is to consolidate all these try blocks where as somehow keep all the errors happening separate even though every call to 'Single' throws the same type of exception (InvalidOperationException)...
Thanks
You are misusing exceptions for control flow. Better:
var foo1 = SomeDataSource.Entities1.SingleOrDefault(x=> x.bar1 == somevalue);
if (foo1 == null) return ErrorCode1;
Very clean and simple.
What's especially vexing in the original code is that you are treating all occurrences of InvalidOperationException as the same thing. Who knows whether that's true or not?! There can be many things throwing this particular exception type. You might hide bugs by catching too generously. You might even hide EF bugs this way.
If you want to move your business logic into the lambda method, which it sounds like, you can do so by defining an extension.
Note: I am not endorsing the code below at all; I'm just trying to make it fit the question that you have asked.
public static class LinqExtensions
{
public static ErrorCode BusinessSingle(this IEnumerable<TSource> enumerable, Func<TSource, bool> predicate)
{
TSource result;
try
{
result = enumerable.Single(predicate);
return new NoError(); // ????
}
catch
{
return new ErrorOne();
}
}
}
But it would be far better to do one of the following:
If errors are common, then don't treat it like an Exception but rather a validation rule.
If errors are exceptional, then throw Exception that are differentiated.
You're right that if you're always expecting exactly one element to match your condition, you should use Single() rather than SingleOrDefault().
That means that if that is not the case, your system is a faulted state, and your application should shut down because it is not working correctly. By saying Single(), you're saying "I know there's exactly one there. If there's not, there's something seriously wrong."
By trying to handle the exception and return an error code instead, you're saying something different. You're saying "There should be exactly one there, but if there's not, I can do something else to handle that case." That's what SingleOrDefault() is for.
Here are two previous questions regarding this topic:
Catch multiple Exceptions at once?
More Elegant Exception Handling Than Multiple Catch Blocks?
I was working today and thought this might be an appropriate syntax should this feature ever be added to the C# language. Anyone have any opinions about it?
The type of e must be a base type or interface of every exception type listed.
Edit: In this example, the catch block handles either ArgumentNullException or ArgumentOutOfRangeException and places the exception instance in a variable of type ArgumentException called e. It doesn't handle any other type of ArgumentException other than the two listed. I think there was some confusion about the associativity of the , and the as.
Edit 2: If the listed exceptions all upcast to a variable of the type of e, then the code compiles cleanly to MSIL without any casts or explicit type checks, making it faster (potentially significantly) than the current syntax of catching ArgumentException followed by a throw; if it's not one of the two you intended. The problem is even more obvious if you're catching Exception and checking for two possible types to handle and rethrowing if it's something else.
try
{
}
catch (ArgumentNullException, ArgumentOutOfRangeException as ArgumentException e)
{
}
See this:
Cool or Stupid? Catch(Exception[NamingException, CreateException] e)
My answer to that question is that they should let you "stack" them like with using blocks:
try
{
}
catch (ArgumentNullException e)
catch (ArgumentOutOfRangeException e)
catch (ArgumentException e)
{
}
Though I see you're going for and rather than or . Personally I don't see the and approach as very useful, because you're already constrained to a real non-interface exception type and there's no dual-inheritance.
Inclusion of this feature is planned for Java 7 with the following syntax:
try {
return klass.newInstance();
} catch (InstantiationException | IllegalAccessException e) {
throw new AssertionError(e);
}
Edit: I think the intention is for the static type of e to be the most specific common superclass of the listed exceptions. (In Java, only instances of class java.lang.Throwable can be thrown, hence catching with a common super interface is of limited utility since the exception can not be re-thrown.)
You can already do this, just
try{}
catch(Exception e)
{}
since all exceptions derive from System.Exception. And you would do just as you would above, determine the type of the exception in the catch block itself.
If ArgumentNullException and ArgumentOutOfRangeException have different interfaces, will be a pain to cast correctly;
For instance ArgumentOutOfRangeException have an ActualValue property; if you had to use it, you'll end with something like:
if(e is ArgumentOutOfRangeException)
{
// use e.ActualValue
}
else
{
// use e.Data
}
I don't find myself wanting this very often in C#, whereas in Java I find there are various situations where I have to catch a bunch of checked exceptions and wrap them all in a different exception that my method is declared to throw.
That's something I'd possibly like some syntax for:
try
{
}
wrap (OneException as AnotherException)
catch (HandleableException e)
{
// Actual handling for some exception types
}
... but again, I find myself doing that much more in Java than in C#.
There are other enhancements which are way higher up my list for C# than this :)
That would only work if you do not declare an instance (e). If you reference the e inside the block, what is it?
There are certain areas in your code that you don't want the program execution to stop, like say during a checkout at a ecomm store.
I was thinking of creating a special 'return' type that looks like:
public bool SpecialReturn
{
public bool IsSucess {get;set;}
public List Messages {get;set;}
}
I could put an enum there to return a ReturnType etc. if I wanted.
Point being, I would then, call my CheckOut process method and return this, so I could then handle the error more gracefully.
is this a good practice?
Program execution doesn't have to stop when you hit an exception.
In general I would recommend throwing an exception when things go wrong. If you don't want that exception to bring down the program then catch it and handle it gracefully.
Of course, there are always situations where returning some sort of status object might be a better idea than throwing/catching exceptions, and your situation might be one of those, but without more information it's difficult to say.
you come from the wonderful world of C don't you?
yes, you can do that. but it wouldn't be useful...
your code can still throw from the ClassLibrery
and handling error codes, well sucks...
throwing exceptions don't stop the program, they just inform the upper level of an unexpected error... try...catch...
you should use exceptions, but well only in exceptional circumstances...
is this a good practice?
I'd say NOT.
Create your own subclass of Exception, add your custom properties as required (to report context info relevant to your needs) and throw.
If you use Visual Studio, there is a good code snippet for that, called Exception.
[Serializable]
public class MyCustomException : Exception
{
public MyCustomException(string myMessage)
{
MyMessage = myMessage;
}
protected MyCustomException(SerializationInfo info, StreamingContext context)
: base(info, context)
{
}
public string MyMessage { get; private set; }
}
//...
throw new MyCustomException("Hello, world!");
If a function can succeed and return a result, or fail and not return a result you could use the same pattern that Microsoft does in a number of places. TryParse being a perfect example.
int result;
if ( Int32.TryParse("MyStringMayFail", out result) )
{
// Succeeded result is usable
}
else
{
// failed result is undefined and should not be trusted.
}
The actual return type of the method indicates success or failure, a parametrised out variable holds the 'result' of any operation the function may be performing. This style of coding enables the end user of the function to code directly on the success or failure of the function.
It is dead easy to create your own implementation of the TryParse methods, they are usually coupled with Parse methods which throw exceptions if something fails during processing.
If it is in fact an 'exceptional' case, and not just a valid failure, it is perfectly reasonable to throw an exception. In your case, you can handle the exception, and continue execution as best you can.
In the end what you are proposing is just recreating what exception handling already accomplishes for you.
Now if the failure is due to a credit card authorization failure (meaning invalid card number, connection failure would require an exception) or something like that. I would use failure codes, and error messages instead of exceptions.