How do you face a programming task that you’ve never done before?
- Thread starter JournalBot
- Start date
Relax, don't worry, and take a couple quick runs at the problem.
Stack Overflow has some pretty good best practices for getting simple things done in a language.
Once you've solved (or tried to solve) the core of the issue once (or twice) you probably have a good idea of how to get it right. Don't be afraid to fail.
Stack Overflow has some pretty good best practices for getting simple things done in a language.
Once you've solved (or tried to solve) the core of the issue once (or twice) you probably have a good idea of how to get it right. Don't be afraid to fail.
Upvote
0
(0
/
0)
As a web developer, I am constantly tasked with figuring out ways of doing things I have never done before. One of the things I have found is that you can't be afraid to try and fail. Sometimes when working on a problem I will have to try three, four or more different solutions before I find one that will work. Some people would give up after their first try, but you can't, because sometimes only with multiple tries will you find the solution you are looking for.
Also, asking your team for help if you get stuck is always an option as well. Someone else may have had to solve the same problem you are working on in another project.
Speaking of other projects, one thing I like to do when struggling to find a solution to a problem is do a search on my company's SVN repo to see if anyone else committed code for another project that does something similar to what I need to do. Sometimes this will turn up a result and will give me a head start or at least a point in the right direction.
Also, asking your team for help if you get stuck is always an option as well. Someone else may have had to solve the same problem you are working on in another project.
Speaking of other projects, one thing I like to do when struggling to find a solution to a problem is do a search on my company's SVN repo to see if anyone else committed code for another project that does something similar to what I need to do. Sometimes this will turn up a result and will give me a head start or at least a point in the right direction.
Upvote
6
(6
/
0)
It's ok to ask when you don't know. But listen carefully, because it's not ok to ask the same thing again.
Upvote
18
(19
/
-1)
I have some comments on the first and last answer:
On essential skill is being able to break down a problem into a number of smaller steps. Diagrams are helpful for a high level overview of what you want to do. Pseudo-code is another good technique to help you flesh out methods. With .NET and Java you can doc methods, if you write these before actually writing the methods themselves it will makes you think about what that method should actually be doing.
As for the third answer, I have to agree with the comments about anything that is termed Generic. There should be a clear set of requirements about how error handling is done. I fear what will happen in this example is something similar to the "inner-platform-effect".
http://en.wikipedia.org/wiki/Inner-platform_effect
On essential skill is being able to break down a problem into a number of smaller steps. Diagrams are helpful for a high level overview of what you want to do. Pseudo-code is another good technique to help you flesh out methods. With .NET and Java you can doc methods, if you write these before actually writing the methods themselves it will makes you think about what that method should actually be doing.
As for the third answer, I have to agree with the comments about anything that is termed Generic. There should be a clear set of requirements about how error handling is done. I fear what will happen in this example is something similar to the "inner-platform-effect".
http://en.wikipedia.org/wiki/Inner-platform_effect
Upvote
5
(5
/
0)
As an indie game dev starting essentially from knowledge scratch, this is basically my whole life. The biggest takeaway I've found so far is the fact that nobody is an island, especially in 2014. There's a good chance that somebody, somewhere has done something similar to what you're working on. And it's usually just a Google away. Don't be afraid to ask smart questions, but like what was mentioned above, try not to ask the same thing twice. You have the benefit of working in a company around presumably smart people that could give you a hand here and there.
And like a lot of people have already said, figure out the best way for you to solve each problem individually. Diagram it, break it down. Difficult problems become much more manageable when broken down into actionable sections.
Last and probably most important, forget the attitude of "I don't know if I can do this." I know its cliche, but stop being negative and start asking yourself "what do I need to do to finish this?" If you admit defeat at the start, you aren't going to ever make it to the finish line.
And like a lot of people have already said, figure out the best way for you to solve each problem individually. Diagram it, break it down. Difficult problems become much more manageable when broken down into actionable sections.
Last and probably most important, forget the attitude of "I don't know if I can do this." I know its cliche, but stop being negative and start asking yourself "what do I need to do to finish this?" If you admit defeat at the start, you aren't going to ever make it to the finish line.
Upvote
6
(7
/
-1)
I would (almost) begin a "generic error handling mechanism" task with a conversation with team members, either individually, or together. What do we all want to see this "thing" do? In this particular case, especially, your team, and your wider IT department, are the "customers" of your product. You need to collect requirements.
But before I did that I would arm myself with some preliminary studies. Research if there are any "tutorials" or "examples" already out there, perhaps on CodeProject. I'd also try to find some "luminaries" opinions floating around. Then, I'd look at some larger open source projects that would have error handling, to see how they're doing it, and also try to dig up complaints about existing error handling.
That last point is a good one. Research the common problems with error handling and see if any apply to the particular situation, so that they can be avoided up front.
Research then Discussion. That's how I usually start.
EDIT: Cleared up what exactly I would begin with...
EDIT2: I agree about that word "generic". What needs to be "generic" here? The task is to handle errors. I would say "consistent" is probably better than "generic". With error handling it's almost as much convention as "library" or whatever. The team has to agree how they're all going to be handling errors - so that everyone isn't doing their own thing. "Generic" would seem to apply if multiple teams would be using this "error handling mechanism" across multiple projects.
But before I did that I would arm myself with some preliminary studies. Research if there are any "tutorials" or "examples" already out there, perhaps on CodeProject. I'd also try to find some "luminaries" opinions floating around. Then, I'd look at some larger open source projects that would have error handling, to see how they're doing it, and also try to dig up complaints about existing error handling.
That last point is a good one. Research the common problems with error handling and see if any apply to the particular situation, so that they can be avoided up front.
Research then Discussion. That's how I usually start.
EDIT: Cleared up what exactly I would begin with...
EDIT2: I agree about that word "generic". What needs to be "generic" here? The task is to handle errors. I would say "consistent" is probably better than "generic". With error handling it's almost as much convention as "library" or whatever. The team has to agree how they're all going to be handling errors - so that everyone isn't doing their own thing. "Generic" would seem to apply if multiple teams would be using this "error handling mechanism" across multiple projects.
Upvote
0
(0
/
0)
By being asked to create a generic error message system, you've been asked to predict every possible problem you will encounter while building something you haven't even started designing.
Start by building something. I promise you the errors will flock to you like it's the newest trendy hanging out spot.
Start by building something. I promise you the errors will flock to you like it's the newest trendy hanging out spot.
Upvote
0
(0
/
0)
[url=http://meincmagazine.com/civis/viewtopic.php?p=26198953#p26198953:3mcip297 said:
I think this is a key point. There is no shame in a lack of knowledge. I think I've seen more train wrecks from pride and refusing to ask for help than anything else.
Upvote
8
(8
/
0)
Upvote
0
(1
/
-1)
I'd say "traditional engineering" but the cool kids would start shouting "waterfall" and throwing things.
Upvote
6
(6
/
0)
Your first task should be to start to model your requirements. No, you don't need to bust out the UML diagrams but you do need to ask questions to determine what the problem space looks like and how things fit together.
- what kinds of things are errors? (exceptions, data quality issues, data integrity issues, business logic problems, business process issues)
- who produces them? (code, database logic, monitoring systems, reporting systems)
- who consumes them? (loggers, reporting apps, notification systems, people ...)
Asking yourself and others: who is involved, what is involved, and how do these fit together is the first stage in building a high level requirements model. This will structure the problem space into smaller chunks which you can then use to look for potential solutions.
Once you have the model it is then a good idea to look for established solution patterns - eg MS enterprise blocks - but you should hold off on that until you have your requirements model clear to avoid jumping to a great solution to a different problem!
- what kinds of things are errors? (exceptions, data quality issues, data integrity issues, business logic problems, business process issues)
- who produces them? (code, database logic, monitoring systems, reporting systems)
- who consumes them? (loggers, reporting apps, notification systems, people ...)
Asking yourself and others: who is involved, what is involved, and how do these fit together is the first stage in building a high level requirements model. This will structure the problem space into smaller chunks which you can then use to look for potential solutions.
Once you have the model it is then a good idea to look for established solution patterns - eg MS enterprise blocks - but you should hold off on that until you have your requirements model clear to avoid jumping to a great solution to a different problem!
Upvote
3
(3
/
0)
Easiest way of programming something you have not done before - is to break it down into smaller parts. It is likely that even if you don't know how to do the main task - you do know how to solve the smaller ones.
Upvote
0
(1
/
-1)
Abhi Beckert
Ars Tribunus Angusticlavius
That's a pretty important piece of the application... one that should probably be handled by one of the "old hands" at the company.
If you get it wrong you will screw up the workflow of all your colleagues. Is it actually assigned to you or are you just giving it an example of one of the tasks the entire team has to complete?
The best way to face a task you've never done before is to re-assign it to someone who has tons of experience in that task.
When that isn't an option, you should spend ~6 days discussing the problem among your colleagues and searching google (more discussions than google searches). Then spend 3 days actually working on the task.
If it needs 6 days of work, then you need to increase the discussion part to 12 days, and so on.
In my opinion new employees should not be taking on new projects. They should be fixing bugs/maintaining old projects. Then once they understand how things work, they can start working on new projects.
I've heard that inexperienced coders at Apple aren't even allowed to write any code. Their first role is just to manage the bug tracker, taking bug reports filed by other people and figuring out how to reproduce the bug and writing additional details so that someone else can actually fix it. As they get better, they might start writing in a suggestion of how it should be fixed, and this is around the time when they're likely to be assigned to a role at the company. I would love to try implementing this system where I work one day, it sounds like a great way to make sure your new employees really understand the codebase before they start working on it.
Upvote
-16
(1
/
-17)
1st step is always MSDN and then Bing.
In this case the basic MSDN search didn't find much. The Bing search returned the Patterns and Practices's Exception Handling Block as the second link.
See it might have actually been a trick question, no one really wanted you to develop it on your own, and if they did they wanted you to adapt it from the P&P library. Maybe a light version of it as the Exception Handling Block may have been overkill. Either way you'd have practical source code and you'd know how to solve the problem.
In this case the basic MSDN search didn't find much. The Bing search returned the Patterns and Practices's Exception Handling Block as the second link.
See it might have actually been a trick question, no one really wanted you to develop it on your own, and if they did they wanted you to adapt it from the P&P library. Maybe a light version of it as the Exception Handling Block may have been overkill. Either way you'd have practical source code and you'd know how to solve the problem.
Upvote
0
(1
/
-1)
Wow, a generic error handling mechanism for the whole project.
On the good side, your manager probably realized that error handling, because it happens everywhere, is probably not tightly coupled to any other part of the project. In this way, it is easier to give to a young developer who isn't seeing the big picture very clearly yet.
On the rather more difficult side, error handling is a topic for mature coders. I know my own thinking about error handling has gone through several phases in a long career. Questions like return codes vs exceptions, localization of error messages, error recovery strategies, are all very sophisticated topics that a new developer has no hope of mastering.
You may discover that your boss really meant something vastly simpler than you think, like "Write a set of functions for copying error message text to a log file," or "Set up a couple of header files with ranges of error constants for different classes of errors." This you can probably do easily. If your boss really meant develop a whole strategy for handling errors, they get credit for thinking of the idea, but no credit for handing this important task to a new guy.
But bosses want what they want, and there's maybe nothing you can do but try to give it to them. In that case, google is your friend. You can google "error handling", "error reporting", "error reporting in C#", "error printer", and related terms and find out what packages other people have put together. Looking at the list of features of several error logging packages and asking yourself why this feature was choses will allow you to reverse-engineer a list of requirements. Seeing how different people solved the same problem might give you a sense of which implementation ideas were best, so you can recommend or code up a specific solution. This is going to get you about halfway to your goal, providing an error printing or logging facility. Having produced *something*, you may be able to fall back on "Well, I've only been doing this for three months, what did you expect?" Otherwise, I think that defining overall how the whole app will handle and recover from errors is a discussion that the whole team will have to participate in. It's extremely naive to think one person can define it. (Nevertheless, I once had a boss who was angry at me because I could not poof this problem out of existence for him.)
On the good side, your manager probably realized that error handling, because it happens everywhere, is probably not tightly coupled to any other part of the project. In this way, it is easier to give to a young developer who isn't seeing the big picture very clearly yet.
On the rather more difficult side, error handling is a topic for mature coders. I know my own thinking about error handling has gone through several phases in a long career. Questions like return codes vs exceptions, localization of error messages, error recovery strategies, are all very sophisticated topics that a new developer has no hope of mastering.
You may discover that your boss really meant something vastly simpler than you think, like "Write a set of functions for copying error message text to a log file," or "Set up a couple of header files with ranges of error constants for different classes of errors." This you can probably do easily. If your boss really meant develop a whole strategy for handling errors, they get credit for thinking of the idea, but no credit for handing this important task to a new guy.
But bosses want what they want, and there's maybe nothing you can do but try to give it to them. In that case, google is your friend. You can google "error handling", "error reporting", "error reporting in C#", "error printer", and related terms and find out what packages other people have put together. Looking at the list of features of several error logging packages and asking yourself why this feature was choses will allow you to reverse-engineer a list of requirements. Seeing how different people solved the same problem might give you a sense of which implementation ideas were best, so you can recommend or code up a specific solution. This is going to get you about halfway to your goal, providing an error printing or logging facility. Having produced *something*, you may be able to fall back on "Well, I've only been doing this for three months, what did you expect?" Otherwise, I think that defining overall how the whole app will handle and recover from errors is a discussion that the whole team will have to participate in. It's extremely naive to think one person can define it. (Nevertheless, I once had a boss who was angry at me because I could not poof this problem out of existence for him.)
Upvote
2
(3
/
-1)
Analysis paralysis is common with all new engineers regardless of discipline. Try not to over think your problem. Take a chunk and get started - be it a diagram or pseudo code or something. That will get your brain in the right gear so you can ask intelligent questions of Google, your coworkers, etc.
Upvote
2
(2
/
0)
Abhi Beckert
Ars Tribunus Angusticlavius
Sure... but he's talking about handling exceptions, which is one of the most difficult subjects any programmer will ever tackle.[url=http://meincmagazine.com/civis/viewtopic.php?p=26200175#p26200175:3clg3c82 said:
There's an exception to every rule and this is one where serious analysis is needed.
Upvote
0
(1
/
-1)
If I wasn't being handed problems I'd never encountered before every single day, I'd have given up on this career a long time ago. Seriously, who wants to reinvent the wheel for decades on end?
If you don't know how to even approach solving a new problem, let alone enjoy it, programming is probably not the career for you.
If you don't know how to even approach solving a new problem, let alone enjoy it, programming is probably not the career for you.
Upvote
2
(2
/
0)
Prototyping on something like Ruby on Rails is a great way to get from zero to complete product in a day or so. For example we wanted to add 2-factor auth onto our site, so I made a quick rails project, made a trivial login, and then added 2fa. It was a great way to show the feature off and get real feedback.
An important aspect of prototyping is getting something up fast, and figuring out if it is a good idea or not.
Rubber ducking works too. Just get another person from the team and start talking about it. The more you try to explain the better your ideas formulate. A good rubber duck will also help point out strengths in your ideas to help steer you.
Drawing diagrams falls into the rubber ducking category.
I also like the "stupid impl" -- a implementation that gets the job done as fast as possible with terrible names. Then start thinking abstractions, etc. but a terrible first version usually morphs into a great 2nd or 3rd version.
An important aspect of prototyping is getting something up fast, and figuring out if it is a good idea or not.
Rubber ducking works too. Just get another person from the team and start talking about it. The more you try to explain the better your ideas formulate. A good rubber duck will also help point out strengths in your ideas to help steer you.
Drawing diagrams falls into the rubber ducking category.
I also like the "stupid impl" -- a implementation that gets the job done as fast as possible with terrible names. Then start thinking abstractions, etc. but a terrible first version usually morphs into a great 2nd or 3rd version.
Upvote
2
(2
/
0)
Oh god. Step 1 is get more requirements, easily.
Is this exceptions ala Java?
Is this some kind of central event handler?
I mean, if I have an exception, I probably want a few discrete things in place:
1 - Error catching, since I don't want to exit the process altogether, just switch to a different logic flow
2 - Logging. Duh.
3 - Event handling - I may want to fire off an event somewhere to clean up or something when time permits (in a separate thread, while this thread goes on to the next task or whatever)
Is this exceptions ala Java?
Is this some kind of central event handler?
I mean, if I have an exception, I probably want a few discrete things in place:
1 - Error catching, since I don't want to exit the process altogether, just switch to a different logic flow
2 - Logging. Duh.
3 - Event handling - I may want to fire off an event somewhere to clean up or something when time permits (in a separate thread, while this thread goes on to the next task or whatever)
Upvote
0
(0
/
0)
Unless these are new technologies to the company, I'd hope that this has already been done on prior projects, which should give you a starting point. If you're breaking new ground, what mechanism was used on the stack that they were using? What was good? What was bad, what's desired now? Go from there.
Upvote
1
(1
/
0)
Oh god, I'm so tired of the belief that everything starts with excessive planning and research.
MANY projects, absolutely, yes. You'd waste so much time designing a game engine without some plan of its structure. BUT, the same is simply not true at all for the article title: Something "you've never done before".
If you're entering new concepts, you're going to need at least a little bit of trial and error. I think some more experienced coders simply assume that some concepts, or even designs, will make perfect sense to someone after just reading about it in a textbook, and that you can move on to UML diagrams. But no good physics professor will simply describe the concepts of static coefficient of friction without also showing you the concept at work, and then having you try it out yourself with blocks on a ramp.
I've read all sorts of books on the graphics pipeline of DirectX, and some part of me thinks that I understand it. But, if I were ever making an engine from scratch, I'd absolutely need to do a "trial run" that does nothing but load and render sets of models; because getting the structure of that wrong could end up meaning redesigning my engine. ("Well, shoot! THAT part needs to be loaded first...? And it will SOMETIMES finish AFTER that other part?")
This is just for your own learning though, and some code will need to be written with the knowledge that you're going to throw it away; starting again thinking "Okay! I know what I was doing wrong on that last attempt, and I'm going to design the real thing a bit differently". Don't get so far that someone looks over your shoulder and says "L0K GRATE! SH1P IT111"
MANY projects, absolutely, yes. You'd waste so much time designing a game engine without some plan of its structure. BUT, the same is simply not true at all for the article title: Something "you've never done before".
If you're entering new concepts, you're going to need at least a little bit of trial and error. I think some more experienced coders simply assume that some concepts, or even designs, will make perfect sense to someone after just reading about it in a textbook, and that you can move on to UML diagrams. But no good physics professor will simply describe the concepts of static coefficient of friction without also showing you the concept at work, and then having you try it out yourself with blocks on a ramp.
I've read all sorts of books on the graphics pipeline of DirectX, and some part of me thinks that I understand it. But, if I were ever making an engine from scratch, I'd absolutely need to do a "trial run" that does nothing but load and render sets of models; because getting the structure of that wrong could end up meaning redesigning my engine. ("Well, shoot! THAT part needs to be loaded first...? And it will SOMETIMES finish AFTER that other part?")
This is just for your own learning though, and some code will need to be written with the knowledge that you're going to throw it away; starting again thinking "Okay! I know what I was doing wrong on that last attempt, and I'm going to design the real thing a bit differently". Don't get so far that someone looks over your shoulder and says "L0K GRATE! SH1P IT111"
Upvote
-1
(1
/
-2)
"Fail often, fail fast" is a good way to go. Say you are working with a binary tree. Do you start at the bottom or the top of the tree? Do I use a for loop, or do I use a recursive call?
You have to pick one, and usually only one is going to get you the best results with the cleanest, simplest code. You might get lucky and it works either way, you may get lucky and choose the right direction. But there is no sense overthinking it so you can get it right the first time, knowing a certain approach isn't going to work is more valuable than analyzing a problem to death and not writing any code. Even if you are wrong, you at least get your unit tests out of the way, which will also provide insight. Or in terms of an proof by induction you will also gain plenty of insights just working out a few base cases.
You have to pick one, and usually only one is going to get you the best results with the cleanest, simplest code. You might get lucky and it works either way, you may get lucky and choose the right direction. But there is no sense overthinking it so you can get it right the first time, knowing a certain approach isn't going to work is more valuable than analyzing a problem to death and not writing any code. Even if you are wrong, you at least get your unit tests out of the way, which will also provide insight. Or in terms of an proof by induction you will also gain plenty of insights just working out a few base cases.
Upvote
1
(1
/
0)
Gather requirements. Find out exactly what the team is looking for. Spend an hour reading up on the topic.
Look to see if there's an open source solution to the problem with a compatible license.
If not, figure out the simplest system that solves part of the problem. For exception handling, this could be a single try-catch around your entire program that logs the exception and restarts the program. Congratulations, you've now avoided failing the task! In my experience, it's much better to present a simplistic solution that barely addresses the problem then a well designed solution that doesn't work.
Now that you've made sure you won't get to the deadline with nothing, iterate. Make the logging configurable. Add some inner exception handling for cases that can be gracefully recovered from. Read more on the topic to see what other people have built.
Again, try to get each iteration working as quickly as possible. When you're in territory you've never dealt with before, you want to work in short sprints. A few days of coding and testing, and the system runs and is slightly better than before. Repeat.
Look to see if there's an open source solution to the problem with a compatible license.
If not, figure out the simplest system that solves part of the problem. For exception handling, this could be a single try-catch around your entire program that logs the exception and restarts the program. Congratulations, you've now avoided failing the task! In my experience, it's much better to present a simplistic solution that barely addresses the problem then a well designed solution that doesn't work.
Now that you've made sure you won't get to the deadline with nothing, iterate. Make the logging configurable. Add some inner exception handling for cases that can be gracefully recovered from. Read more on the topic to see what other people have built.
Again, try to get each iteration working as quickly as possible. When you're in territory you've never dealt with before, you want to work in short sprints. A few days of coding and testing, and the system runs and is slightly better than before. Repeat.
Upvote
1
(1
/
0)
I really like the second answer. When I graduated with my BS in CS two years ago my first job was consulting and every time I rolled onto a project I was nervous and didn't know if I could do it. A lack of confidence in my skill and abilities is something I actually recognized during my undergrad work, so it's something I have been able to identify and work on. Now I'm working in R&D with people who have PhDs and people who have have 20-30 years of industry experience and it's easy to feel dumb or unqualified. But they hired me knowing my experience, I'm learning things constantly, and it's tough, but it's basically my dream job for where I'm at in my career. If I'm unclear on something it's just a matter of asking for an explanation, and it slowly is all coming together (and changes constantly so I have to figure it out again). Your manager knows your experience and it is their job to match that with tasks that you are capable of completing, while also learning and becoming more familiar with the tools and best practices (but this also doesn't absolve you from pushing hard if they assign you a difficult task).
I also really rely on getting small things working at a time (like prototyping) and integrating that with the rest as it slowly comes together then adding robustness, error checking, better/proper memory management, etc. But just cause that works for me doesn't mean it will work for everyone, get a methodology and approach that works for you and makes sense for you.
That's the fun of it, isn't it? Learning, solving interesting problems, and constantly improving.
I also really rely on getting small things working at a time (like prototyping) and integrating that with the rest as it slowly comes together then adding robustness, error checking, better/proper memory management, etc. But just cause that works for me doesn't mean it will work for everyone, get a methodology and approach that works for you and makes sense for you.
That's the fun of it, isn't it? Learning, solving interesting problems, and constantly improving.
Upvote
1
(1
/
0)
Abhi Beckert
Ars Tribunus Angusticlavius
And use it for inspiration, but don't actually use the code unless it's a *huge* project with a years of stability under it's belt.[url=http://meincmagazine.com/civis/viewtopic.php?p=26202327#p26202327:11sk7rqn said:
Almost all code has bugs, and you really want the bugs to be in your own code - not in somebody else's code.
Upvote
-2
(0
/
-2)
[url=http://meincmagazine.com/civis/viewtopic.php?p=26201903#p26201903:sqwvt7sh said:
Nobody has said it's not an iterative process, but to suggest you do not need research or planning (I would love to hear what you call 'excessive') before getting into it is a sign of shoot-from-the-hip development that leads inevitably to spaghetti code nobody understands 3 weeks after it's written.
[url=http://meincmagazine.com/civis/viewtopic.php?p=26201903#p26201903:sqwvt7sh said:
Sometimes little scratch programs are useful but they are by no means required. If you're smart, you'll even write those with classes/functions that you can copy/paste verbatim into the real engine when you're done testing. There is no reason to get lazy just because you're writing test code, even if the code is strictly to educate yourself.
Upvote
2
(2
/
0)
the key is to educate yourself. Research the topics, identify two or three different approaches and learn them. Then take what you are doing and pick the approach that fits best. Be prepared to perform re-work. Work on a software design strategy before you start coding. Look for feedback on your design from more experienced developers and take their input. Then start coding.
Upvote
0
(0
/
0)
Generic error handler in .net:
1. Catch the error
2. Assign error code
3. determine severity (FATAL, REMEDIAL)
4. Schedule event to report error. (Event generator can email error, etc)
5. Look up table that contains error code for reference by help desk.
Derive custom Exception class from Exception. Re-throw this exception when generic exception is caught.
try
{
float f = 100/0;
}
catch(Exception ex)
{
int ErrorCode = 100; //Error code that help desk will look up
//MyCustomException will create an Event that will email the help desk
throw new MyCustomException(100, "Problem Creating float", ex);
}
1. Catch the error
2. Assign error code
3. determine severity (FATAL, REMEDIAL)
4. Schedule event to report error. (Event generator can email error, etc)
5. Look up table that contains error code for reference by help desk.
Derive custom Exception class from Exception. Re-throw this exception when generic exception is caught.
try
{
float f = 100/0;
}
catch(Exception ex)
{
int ErrorCode = 100; //Error code that help desk will look up
//MyCustomException will create an Event that will email the help desk
throw new MyCustomException(100, "Problem Creating float", ex);
}
Upvote
-1
(0
/
-1)
Seems pretty easy, but much depends on what your manager actually wants.[url=http://meincmagazine.com/civis/viewtopic.php?p=26209545#p26209545:10rk6mb4 said:
Most important, error reporting is not the same as error handling. If the manager asks for a strategy to handle errors, they may be asking how to structure the whole program so that execution can (optionally) continue after an error. The error must be disposed of, which means you need to know what the error implies. Is this an unrecoverable fatal error? Is this an error in the program's main event loop that might in principle be handled just by swallowing it and getting the next event? Does this error imply an entire subsystem is unavailable, but other subsystems may still be functioning? Is this error the cascading failure from a previous error, so that execution should be terminated even though in other circumstances, the error might be non-fatal? Can this program be divided into major sections (e.g. run/stop or startup/main loop/shutdown) where the response to an error may be different?
The basic choice of how error information propogates through the system is important. If every error can be defined by an integer code, then returning an error code may be the most appropriate method. If you want to have contextual information, like a filename or URL, then maybe you'd rather return boolean pass/fail and fill in an error structure that is an out-parameter of every function, or (gasp) a global errno variable.
Some people like exceptions, and other people hate 'em. Google, for instance, has decreed that no exceptions be thrown in C++ code. But this is difficult because C++ is defined to throw for out-of-memory errors, and for bad dynamic cast to non-pointer. Windows also throws "structured exceptions", which you have to handle and convert to return codes if you want your program to do anything but halt suddenly. And you almost always want that. Some people think exceptions reduce the complexity of the code, because they count only visible execution paths. Others think exceptions increase the complexity of the code, because they count all possible paths. Some languages and some libraries are defined to throw exceptions, which means if you want to return error codes, you must remember to wrap all such calls or your program will terminate abruptly.
If you really want your program to remain available, you have to account for all possible errors. In Windows, some library functions call a function called abort(), which mostly does just waht it says. You can take control of abort() to prevent it terminating your code. Runtime checks in Windows call a different function that behaves like abort() but is literally different. There's signals, like control-C that will stop your program inelegantly if you don't handle it.
A complete error handling strategy is so complex that even experienced developers can easily miss something unless they've spent a lot of time thinking about errors. It's something that sounds easy, but has layers of complexity and tomes of arcane lore buried inside.
Upvote
-1
(0
/
-1)
- Status