Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When something goes wrong in your program, you can throw an exception in your code with a message that describes a problem. Typical example:
throw new Exception("Houston we have a problem");
Is it a good practice to pass a hardcoded string into an exception constructor? Maybe I should hold all of exception messages in a one place. Please tell me what's the best practice to solve a problem of exception message structuring.
As Tim mentioned in the comments already localization can be a problem if the messages are shown to users.
What my approach on this topic is, and what I really like to suggest is the following.
Try to make it generic.
Makea a constants class holding your exception Messages with meaningfull constants names like this:
public static const String IN_VARIABLE_MISSING = "An expected value is missing. Please try again";
This will give you the ability to actually re-use the exception wherever it is needed. ( Also you only need to edit it at one place and have it updated everywhere ) You can build a wrapper which will handle the localization. But there are so many options for that topic, that I will not elaborate too much.
So you then can throw an exception like this:
throw new Exception(IN_VARIABLE_MISSING);
If this is software which will be used commercial I would also recommend to write an own Exception which extends the standard Exception.
Why?
You can create an exception that will take your message and an number for example and will automatically build an unique key for you like this:
IN-MODULE-NUMBER-IDENTIFICATION
You see where that could be handy? Excactly in localization and in faster finding of where it happened and why it happened.
You can modify it to write IN at the beginning for Internal errors. VA for validation errors. Then the class/project where it happened and then a number or whatever you want.
This system will also give you the ability to use another string for that key depending on the locale the user is using.
TL;DR Make it reusable!
Is it a good practice to pass a hardcoded string into an exception constructor?
Yes and No.
No in the sense that this code:
throw new Exception("Houston we have a problem");
is much harder for the caller to deal with. That's because what the exception means is identified only by the text of the message; therefore a caller wanting to catch exceptions from your code (for example, so as not to crash but continue running if possible) has to make string comparisons to figure out what the problem was.
e.g.
try
{
someService.DoSomething(sessionId)
}
catch(Exception ex)
{
if (ex.Message.Contains("Houston"))
{
//this indicates that someService couldn't connect to the database
}
else if(ex.Message.Contains("is on fire"))
{
//someService detected that the network is exploded
}
else{
//we can only handle the two previous cases, all else is passed on}
throw;
}
As you can see this gets messy fast, and if someone changes the text....
Now this code, on the other hand:
throw new SomethingSpecificWentWrongException(sessionId);
where SomethingSpecificWentWrongException might look like this:
public class SomethingSpecificWentWrongException: Exception
{
public int SessionId {get;protected set;}
public SomethingSpecificWentWrongException(int sessionId):
base($"Something specific went horribly wrong with session {sessionId}")
{
SessionId=sessionId;
}
}
can easily be handled by the caller:
try
{
someService.DoSomething(sessionId)
}
catch(SomethingSpecificWentWrongException ex)
{
//do whatever it is you do to recover from this
}
catch(SomethingElseSpecificWentWrongException wex)
{
//recover from this
}
else
{
throw;
}
You'll notice that there is a hard-coded-ish string here but it's owned by the custom exception class itself, not by the code that decides to throw the exception; this makes a big difference because it means you can guarantee that wherever this exception is used the message is predictable (in terms of logging, etc).
So not only is it easier to reason about, it's a lot more maintainable than hard-coding strings provided by the throwing code.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am wondering what is the best way to warn about a data that a user has to provide is missing or wrong.
Exceptions, for me, are when there are something exceptional that I can't control, for example, if i try to write a file, there is no permissions or the hard drive is full. If I am querying database, the database is down or the LAN connections doesn't work... etc.
But if it is because a user doesn't provide a needed information or it is incorrect, this is something that I have control over it, so from some point of view, it is not an exception, because it depends on me. But if I don't use exceptions, to warn the user, I have to show a dialog, so the code it is much more complex if I have considerate all the possibilities.
For example, with exceptions I could have this code:
try
{
if(esData1Correct() == false) throw new Exception("Data1 incorrect");
if(esData2Correct() == false) throw new Exception("Data2 incorrect");
if(esData3Correct() == false) throw new Exception("Data3 incorrect");
// All is correct, I continue with the code.
}
catch(Exception ex)
{
MessageBox.Show(ex.Message);
}
However, if I want to use dialogs, the code that I should use, or the code that I think I would have to use is something like that:
if(esData1Correct() == false)
{
MessageBox.Show("Data1 is incorrect.");
}
else if(esData2Correct() == false)
{
MessageBox.Show("Data2 is incorrect.")
}
else if(esData3Correct() == false)
{
MessageBox.Show("Data3 is incorrect.")
}
else
{
// All is correct, so I can continue with my code.
}
So which code is more correct, to use exceptions or messages to warn the user the information is not correct? Are there another better options?
Thanks.
So which code is more correct, to use exceptions or messsages to warn
the user the information is not correct? Are there another better
options?
Neither is more correct and they both show the message to the user with or without the exceptions; mission accomplished. Indeed, you wouldn't warn the user with an exception per say so it's transparent to them anyway unless you plan to dump the stack trace to the UI (don't!!). There are things to consider when using exceptions and you certainly don't want to use them everywhere for everything but it's not wrong to use them for validation failures. Read on for more.
Exceptions are meant for exceptional conditions but what constitutes an exceptional condition varies. Linq's First, for example, will throw an exception if the source or predicate is null, the source is empty, or there's no element that matches the predicate. They could have just returned null but they chose to instead push the responsibility onto the caller to get it right. To me, that's a reasonable use of exceptions where it wasn't exactly necessary; a collection not containing an element that matches a predicate happens all the time so it's not exactly exceptional. And it's not uncommon to see ArgumentExceptions and ArgumentNullExceptions used in similar cases as yours; that's probably how I'd do it absent a more sophisticated approach.
But, first thing's first. I know this is an example but there are some pain-points that need to be addressed before worrying about which approach is more appropriate.
The following is objectively stinky:
try
{
if(esData1Correct() == false) throw new Exception("Data1 incorrect");
if(esData2Correct() == false) throw new Exception("Data2 incorrect");
if(esData3Correct() == false) throw new Exception("Data3 incorrect");
//All is corerct, I continue with the code.
}
catch(Exception ex)
{
MessageBox.Show(ex.Message);
}
Here, the code is using exceptions as control flow. You know something is wrong and can handle it at that point but instead throw and catch an exception to show the message; not good.
Also, don't throw or catch System.Exception. Exceptions, if used, should be specific enough to do something meaningful about it based on the context. Again, it's a small example but this sort of thing is everywhere in naive code.
Having said that, the first example would change and would not catch the ArgumentException if thrown. Let the caller catch the errors as they're the ones creating the exceptional condition; in other words, pull the validation out. The caller should also worry about what to do about it. As it is now, the validation code is tightly coupled to a message box which makes it difficult to reuse.
public Foo Bar(...)
{
// A better way may be to validate them all and return a message
// that aggregates all incorrect data back...
if(!esData1Correct()) throw new ArgumentException("Data1 incorrect");
if(!esData2Correct()) throw new ArgumentException("Data2 incorrect");
if(!esData3Correct()) throw new ArgumentException("Data3 incorrect");
// more ?
}
Given we're willing to remove the coupling to the message box, the second example doesn't really do what we want so instead create a ValidationResult class that can help you build a meaningful message to the user.
I prefer second option, since it uses less resources, and is less complex.
Exception throwing should be used when you want to delegate exception handling to client-module which triggers your code and thus knows more about context in which your code is executed. There is not much sense in handling exception inside same method which throws it. You are right about that - in this example you know everything about what went wrong, and there is no need for exceptions, you just detect error and notify user about it, and that's all.
The rule is generally: Exceptions should be exceptional.
A few examples:
var username = input.Text;
if (string.IsEmptyOrNull())
{
// Give the user a chance to correct the input, this should not be an exception!
}
However, in an API, you might have a method that accepts a user object parameter:
var user = db.usernames.where(x => x.Id == user.Id).FirstOrDefault();
If the input is supposedly already validated, but suddenly can't be found this is an exception. Something really weird happened! But if your query is an attempt to validate it should be treated as a valid query with no results:
var user = db.usernames.Where(x => x.username == user.username).FirstOrDefault();
if (user == null)
{
// return useful error, this is not an exception
}
It depends, mostly you handle the common conditions that are likely to happen (such as database connection in your example) by using simple if statement. Other situations that might occur and you think your code won't cover all of them, use Exceptions, this way you ensure that you catch the error trace.
Some other cases might need both if and Exception.
example :
try
{
if(!string.IsNullOrEmpty(someString))
{
someClass.Run(someString);
}
}
catch(Exception ex)
{
// Log exception
}
as the example above (sorry couldn't think of a real-world case). We used try/catch to catch any unhandled errors, while in the same time, we already validating some known conditions in the try block.
So, it depends on which part you're dealing with in your code. But in all cases, you're supposed to try handling all other errors. You have always to keep avoiding exceptions in your code as much as possible.
You're the judge on your code, choose whatever you see fits best your code.
Here is A good reference for Best practices for exceptions
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have seen many cases where custom exceptions where created, where only the 3 standard constructor overrides are used with no extra information to it.
In those cases I recommended to use InvalidOperationException because in practice there were no callers that catch those custom exceptions.
For example for use in a default block in a switch statement:
public InvalidSwitchValueException()
: base() { }
public InvalidSwitchValueException(string message)
: base(message) { }
public InvalidSwitchValueException(string message, Exception innerException)
: base(message, innerException) { }
What would you recommend ?
Depends. If you intend to use it like this:
try
{
}
catch (InvalidSwitchValueException)
{
// handle this special case differently
}
catch (Exception)
{
}
It is much neater than:
try
{
}
catch (Exception e)
{
if (e.Message == "Check the message")
{
// handle this special case differently
}
}
If it is just to have a different type, with no intend to catch it anywhere, it don't see the point. If you do, it will improve your code quality. Think what happens if you have multilingual error messages (like .NET itself does). You can't and shouldn't rely on the message! Never!
Eric Lippert makes a good point in comment too:
Is this an exception that should never be caught because it indicates a bug in the caller that should be fixed? If so then design the exception to make the bug easy to find and fix, rather than designing the exception to be easy to catch.
A very useful point in naming exceptions is that if they are thrown, it's easier to find them. As an example: NullReferenceException is the worst to get since (without the call stack) it absolutely gives you nothing to help analyze the problem. A check and throw of a typed exception like CatDidntFindMouseException gives you a starting point and probably a clue what is actually going wrong.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am fairly new to programming and I want to know what is the proper way to structure your error handling. I have searched the internet but I have failed to find something solid about the structure of ALL your try/catch/finally statements, and how they interact with each other.
I want to present my idea of how I think I should structure my error handling in code and I would like to invite everyone check if this is correct. A big bonus would be to back it up with some other research, a common practice of some sort.
So my way of doing this would be to put try statements pretty much everywhere! (I hope I haven't raged everyone by saying this). PS - I also understand about catching different types of exceptions, I am only catching of type 'Exception' just for explanation purposes.
So for example:
I start on Main in a normal console application and then I create an
instance of A.
I then call a member function on it called AMethod1 (a.AMethod1).
A.AMethod1 creates an instance of class B and then calls BMethod1
(b.BMethod1).
This is how I would go about error handling it:
public class Program
{
static void Main (string[] args)
{
//I do not place simple code like below inside the try statement,
//because it is unnecessary and will slow the process down.
//Is this correct?
const int importantNumber = 45;
string name;
IRepositoryFactory repoFactory;
A a;
//And then I put code in 'try' where I feel it may go wrong.
try
{
a = new A();
a.AMethod1();
//Some other code
}
catch (Exception ex)
{
HandleError(ex);
}
}
}
// End of scope of Program! The functions below belong to their relative
// classes.
public void AMethod1()
{
try
{
B b = new B();
b.BMethod1();
}
catch (Exception ex)
{
//Preserving the original exception and giving more detailed feedback.
//Is this correct?
//Alternative - you still could do a normal 'throw' like in BMethod1.
throw new Exception("Something failed", ex);
}
}
public void BMethod1()
{
try
{
//some code
}
catch (Exception ex)
{
throw; //So I don't lose stack trace - Is this correct?
}
}
In summary:
I put all code in try statements (except declarations like shown in
above code)
On the client level (at the start of the call stack) I
catch the error and handle it.
Going down the call stack, I just
throw the Exception so I don't break the stack information.
I would really appreciate some resources that explains how programmers are meant to structure their error handling. Please don't forget to read the comments within the code please.
Here are some good rules of thumb:
If you are going to log the error at the level in question, use exception handling
If there is some way to solve the exception, use exception handling
Otherwise, don't add any exception handling at that level
The exception to the rules above is the UI should ALWAYS (okay, maybe not always, but I can't think of an exception to this rule right off hand) have exception handling.
In general, if you are throwing the same error, as you have in your code, it is a sign you should not handle the exception. End of story.
NOTE: When I say "at that level", I mean in the individual class or method. Unless the exception handling is adding value, don't include it. It always adds value at the user interface level, as a user does not have to see your dirty laundry, a message saying "oops, laundry day" is enough.
In my personal experience most of the exceptions are related to null object reference. I tend to follow null object pattern to avoid lots of check for null values. And also while doing a value conversion I always use tryparse so that i dont stand a chance of null issues. all in all this subject could be discussed from many perspective. if you could be a bit more specific it will be easy to answer.
stackoverflow really isn't an opinion site. It's geared heavily towards specific answers to specific questions.
But you should know that try...catch does have some overhead associated with it. Putting it "everywhere" will hurt the performance of your code.
Just use it to wrap code that is subject to unexpected errors, such as writing to disk, for example.
Also note that the "correct" way depends on what you are doing with those errors. Are you logging them, reporting them to the user, propagating them to the caller? It just depends.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
When is it best to use try and catch? I've gotten angry responses when I answered questions using try and catch (some even -1 me...) I Googled it and found this article and also this stackoverflow question.
I give some examples:
I have a drop down list with time zone IDs, when the user selects his time zone I'm updating the database. In other application i'm pulling this the value from the DB and recalculate the user current time and date. There is an option that the data in the DB is misspelled (hardcoded change in the DB or bug). In the conversion method of the date time of the user I'm using try and catch, which some people told me it is wrong!. I could check the value from the DB using for loop but it is costing more for each time I'm converting the date time...
I have to declare if an XML file is well formatted using this code:
protected bool IsValidXML(string xmlFile)
{
try
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xmlFile);
}
catch(XmlException ex)
{
///write to logger
return false;
}
return true;
}
I can't see any other way to check the xml file.
Sometime I have a part on my application I'm writing to a file. writing to a file can cause exeprtion for many reasons , some other process is using this file while writing or other. so usually I'm using this code:
using (StreamWriter w = new StreamWriter(fs))
{
try
{
w.Write("** (Line) " + someValue + " **" + Environment.NewLine);
w.Flush();
}
catch(IOExeption ex){}
finally
{
w.Close();
}
}
In conclusion I see some ways to use try and catch and ways to not use. The one sentence in the article I saw said If an exception happens, you need to know about it. , but when dealing with a generic application most of the times I know that an exception will happened but most of the times I can't really know why it happened so I can't catch it before (like the examples I wrote) , So when is best to use the try and catch
In the same level in ASP.NET the page has an Error event that you can catch like so:
this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page
Is the event is the same as try catch problem??
How you handle an exception depends on the nature of the exception, and on the context in which it occurs.
Smart people have written excellent articles about the subject, and I certainly can recommend:
How to Design Exception Hierarchies by Krzysztof Cwalina
Vexing exceptions by Eric Lippert
API Design Myth: Exceptions are for "Exceptional Errors" by Krzysztof Cwalina
About your examples:
In case 1 you might indeed want to be defensive. But then make sure that you do something sensible in that catch block.
Case 2 looks reasonable, but you're reading the XML document only to throw it away. Would it no make more sense to also process it?
In Case 3 you are using try finally, which is definitely not the same thing as try catch. In your specific example you don't even need it, as the using statment is already making sure the file will be closed.
From a personal perspective I've always assumed that whatever can go wrong, will go wrong and write my exception handling strategy accordingly. One of my major bugbears with others code is when you get an unhandled exception that could easily have been trapped - it looks messy an if it is production code then it shows a complete lack of knowledge of how your program works and the things that might go wrong.
My approach might be overkill, but if something you are doing can throw an error then it should be trapped. I'm not a huge fan of letting exceptions cascade through the stack and being caught at the top level - I'd prefer to trap them at source, log them and then, if the application allows it continue, or at worst fail gracefully and leave the user (or other developers) understanding what has gone wrong or why.
With web applications we use a slightly different approach. The error (stack trace etc) is logged, so that authorised people can see it and the user is given a cut-down version of the error which tells them something has gone wrong but not the specifics.
Thats my two pence anyway. I'm not sure if the approach is right or wrong, but it works for us and helps us to produce more robust code.
The criticisms of your use of try/catch in this answer were not against using try/catch in general, but against that particular way of using it.
You should capture the exception object (i.e. use catch(SomethingHappenedException e) so you get the available information about what went wrong.
You should catch specific exceptions rather than everything. In the DateTime example, I would try to find what exceptions might be thrown by each of my calls. I would then try and figure out if there was some way of trapping these errors without using exceptions - one of the exceptions that might be caught in that code is a ArgumentNullException. That's an exception, but I should be able to handle that within the flow by first checking that I'm not passing a null zone id.
Finally, if it's not possible to handle those cases within the normal flow of the program, I catch specific exceptions that might plausibly occur, and as closely to the source of the exception as possible.
It might seem a bit more effort but it does save you on debugging time down the road!
For example 1, it would be helpful to see code. It's hard to comment without a more concrete idea of what you're doing.
For example 2, the problem with that code is that it completely hides any error condition. Sure, we'll find out if an xml file is good or bad... but why is the xml good or bad? We can't know. It's not that try/catch is bad: it's that the whole thing is being written at the wrong level. Just write code to read the xml file, and have your error handling around that code.
For example 3, you are again swallowing any helpful exception information, and in fact not doing anything with your try/catch at all. The .Close() call in your finally blocks is completely unecessary, because closing your stream is entirely handled when the stream is disposed by the using block.
In summary, I think what you need to learn here is not that try/catch blocks are bad. It's that swallowing exception information is bad.
I think I can sum up the issues people have had in the past with your questions on try...catch, as well as provide some clarity that should help you in the future.
Your first two examples are caused by data validation errors. The data should be checked for known validation errors before being passed to the conversion function (example 1) or trying to write an XML file (example 2).
There is significant overhead in exception handling, so it should only occur when absolutely necessary. The try...catch pattern is designed for handling unexpected (exceptional) errors, not standard data validation.
Example 3 is almost proper usage. It is a situation where there are unexpected things that may occur that you cannot be prepared for, like an IOException. Catching a specific exception is considered bad form as it can lead to multiple catch blocks or missed handling. Catching the generic Exception object is better, and the exception handling code can determine and deal with the exact type of exception.
Your try...catch block should encapsulate the streamwriter as well, since it is best practice to only have one try...catch per method. If you use try...catch, it must always contain exception handling code. Empty catch blocks or empty finalize blocks are bad form and are not helping the code or anyone who is trying to maintain it after you.
try
{
using (StreamWriter w = new StreamWriter(fs))
{
w.Write("** (Line) " + someValue + " **" + Environment.NewLine);
w.Flush();
}
}
catch(Exception ex)
{
//exception handling code here
}
finally
{
//any clean up code here. The using statement makes it unnecessary for the streamwriter
}
Hope all of this helps answer some questions and bring some clarity to the issue.
In my experience, any external operations (such as interacting with a db or file system, or using 3rd party components) should have a try catch block around it. In my own code, I always try to put in guard clauses to methods to limit the number of exceptions my own code produces, if for example you know that the database won't accept a null First name on a person object, add a guard clause should be added to the top of any save method.
In short, don't rely on exceptions to tell you where your code is going wrong, rather try to cut down the likelyhood of an exception first
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Below is a simplified example of a setup I have. My issue is an exception is thrown at a low level which will then bubble up. However, classes at a higher level do not know what horrors await them when they use the lower level class functions. By this I mean developers will come along and use Class3.DoWork3() without any exception handling for the dreaded 'MyCustomException'.
Am I approaching this all wrong? I don't want to catch and throw the same exception multiple times (I have no need to do any kind of clean up for example in Class2).
public class Class1
{
<exception cref="MyCustomException">description</exception>
public void DoWork1()
{
throw new MyCustomException("I have failed you class1.");
}
}
public class Class2
{
public void DoWork2()
{
var classOne = new Class1();
// Here I can see that DoWork1() will throw a 'MyCustomException'
classOne.DoWork1();
}
}
public class Class3
{
public void DoWork3()
{
var classTwo = new Class2();
// I can no longer see that Class2.DoWork2() will throw a 'MyCustomException'
classTwo.DoWork2();
}
}
In order to clear up some confusion which seems to have been generated in the comments I will put the two solutions which I am considering at present:
Tag DoWork2 with the same MyCustomException comment as Class1
Throw a different exception within DoWork2 and tag it with this
new exception. This option seems the most robust as it would allow a
more detailed log (e.g. where exactly the code fell over in it's
execution path). This way does seem a little over the top for
simplistic scenarios which is why I wonder if (1) is an acceptable
solution to this problem?
One of the major limitations with exception handling in .NET and Java is that there's no standardized means by which code can distinguish between an exception of some type which is thrown from a method for reasons that method expects, versus an exception of that same type which is thrown by a nested method, for reasons the outer method did not expect. If the purpose of a method is to call some user-supplied delegate, the only ways I know of to reliably distinguish between exceptions which are thrown by the called delegate and those which occurred in the process of calling it are either to pass the method an identity token which it will include in any exceptions it throws directly, or else have the method as a matter of policy wrap exceptions that occur while invoking the user-supplied callback. Neither method is terribly elegant.
Because there is no standardized way to identify exceptions which indicate that an operation failed "cleanly" without side-effects, from those which indicate that a more serious problem exists, I would suggest that code shouldn't rely upon "serious" exceptions to prevent "contagious" data corruption. Instead, any time an exception might cause an object to be left in a corrupt state, the object should be explicitly invalidated, to prevent corrupt data from being read from it and copied elsewhere (possibly overwriting what would have been the only good copy). In situations where the corrupted object isn't needed and stack unwinding would cause it to be invalidated, there is no problem. In situations where the object that was invalidated turns out to be essential for system operation, the program should be forcibly shut down and invalidating the object will make that happen more reliably than would throwing a "serious" exception.
Unfortunately, neither C# nor VB.NET provides a very nice pattern for guarding objects in this fashion. VB.NET has somewhat better exception-handling abilities than C#, and the correct pattern (taking action in a finally block based upon what exception was thrown, but without catching the exception) can be implemented, albeit awkwardly, in that language. In C# the only way to find out what exception occurs within a try block is to catch and rethrow, an action which has some side-effects.
There is an excellent interview with Anders Hejlsberg titled The Trouble with Checked Exceptions. (Anders led the team that designed the C# programming language.)
You are falling into the exception aggregation trap. You should probably not be asking "what exceptions could possibly be thrown by lower level systems?" The answer, in many cases, would be a list containing hundreds of unique exceptions.
Instead, you should ask yourself "how can I provide useful information to the developer?" You should document the exceptions that your code is explicitly throwing or, in rare cases, relevant exceptions that are very likely to occur and that the caller may be specifically interested in. The developer who calls your code can determine the necessity of handling those errors or passing that information along to the callers of their code - or simply doing nothing with it. Exceptions are exceptional, after all, and at a certain level it doesn't really matter which database error was thrown - the steps taken in response are the same (e.g. stabilize the environment if possible, write to the error log and terminate execution).