Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If we have a class main and the constructor of main constructs our setupclass and we put this class in a try catch in main.

Theoratically Will all errors go into catch? If they will how will it effect the performance and mantainability? Will the application be crash free?

share|improve this question

closed as not a real question by BЈовић, pdr, Glenn Nelson, MichaelT, Doc Brown Mar 1 '13 at 16:48

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Perhaps you won't have "unhandled" exceptions, but that doesn't mean it'll work. Not even remotely. There's even a line of thoughts (that has a point, I think) arguing that silencing errors like this, rather than crashing and burning loudly, leads to less reliable software as the latter forces you to actually (attempt to) solve each error. – delnan Mar 1 '13 at 15:18
What language/environment is this in? The short answer is No, but for us to give you more details of what will actually happen we need to know what you're working with. – MrFox Mar 1 '13 at 15:20
For .net the answer is clearly "yes", for example consider stackoverflows. Some exceptions are often unrecoverable (access violations/segfaults) And there are certainly other kinds of crashes than unhandled exceptions, such as deadlocks. – CodesInChaos Mar 1 '13 at 15:26
Unanswerable question, I'm afraid. Crash is a nebulous term used by users to include any kind of failure. Without knowing the bounds of the word "crash" no one can tell you how to avoid it ... if you even can. – pdr Mar 1 '13 at 16:08
If by crash you mean an unrecoverable error, it depends on the language. You should be more specific. – Giorgio Mar 1 '13 at 17:38

Your program can still crash or otherwise fail to perform it's tasks:

  • Your exception handling code could have a bug in it; by definition your handler is outside of the code 'protected' by your try / catch, so an error there will still result in a program crash.

  • Just because you handled the exception, doesn't mean you your program state is still sane. Your program could easily end up in a state that is effectively useless, because it's internal state is left in an inconsistent state. You program will then continually throw exceptions, and the end user will be left with no other option but to terminate your program forcibly.

Moreover, because you catch all exceptions, you'll have a much harder time debugging what actually goes wrong in your program, and you can never be sure if the exceptions you see are the results of broken internal state after a previous exception was handled, or a genuine bug.

Better to let your program crash. At least then the end user understands the program broke, and you as a developer will have a much better sense of what broke the program.

share|improve this answer
And a tarnished reputation as a developer – James Mar 1 '13 at 16:33

Yes and no. I work on embedded systems. When an unhandled exception occurs we log it and reboot the system, very similar to what you're suggesting. Maybe 9 times out of 10 the reboot clears up the problem, at least good enough while the exception report is being analyzed for a fix. The other 1 time in 10 we get a continuous reboot cycle, which is enough of a problem unto its own that we keep track of how many reboots have happened and go into a "recovery" mode after a few tries.

At any rate, it's no panacea. It's a small bandage you apply to give you time to fix it for real, and it's only helpful if you get those exception reports and have solid initialization code that truly resets the state of your system.

share|improve this answer

Depends on languaga but probably not.

In c# then other threads generating exceptions will kill the main process off the top of my head.

It's irrelevant though, except for very simple programs, you're likely to end up in an irrecoverable state resulting in bad or lost data which for most users is much worse than the application crashing.

share|improve this answer
Also, C# Automatically rethrows ThreadAbortException at the end of a catch block, preventing it from being permanently caught. – Brian Mar 1 '13 at 15:41
Didn't know that one! – Michael Mar 1 '13 at 15:43
StackOverflowException is by definition uncatchable, also a Program.FailFast call will kill a .NET program unstoppably. – Jimmy Hoffa Mar 1 '13 at 16:09

The appropriate goal is not to make your application "crash free" but to make your application reliable and stable.

It may be possible to reduce or even virtually eliminate crashes with exception handling. However, all other things being equal, this will simply replace crashes with cases in which the program enters an unusable state.

This isn't going to look any better to your users. In fact, it will very likely be worse. At least a crash is a clear, clean failure. A program in a non-functioning state is ambiguous at best. The user may waste a long time to see if the application is frozen or just "thinking". At worst it may actually do damage, continuing to perform actions, but in a corrupt manner.

There is no shortcut to writing good, reliable code.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.