Ok, at university we did a lot of Java. And I can remember the tutor saying "Exceptions are great for debugging applications, but shouldn't be used in deployed applications for error handling".
Now I'm kinda confused, because I feel they provide a lot of flexibility in handling errors. So why shouldn't they be used?
Or is this a typical case of Universities teaching "their" practicies and not those used in the industry?
Jump to PostHere is an excellent codeproject article.
SUMMARY:
* Check it early
* Don't trust external data
* The only reliable devices are: the video, the mouse and keyboard.
* Writes can fail, too
* Don't throw new Exception()
* Don't put important exception information on …
I think you should use exceptions when you need it.
Ok, at university we did a lot of Java. And I can remember the tutor saying "Exceptions are great for debugging applications, but shouldn't be used in deployed applications for error handling".
Now I'm kinda confused, because I feel they provide a lot of flexibility in handling errors. So why shouldn't they be used?
Or is this a typical case of Universities teaching "their" practicies and not those used in the industry?
Writing code with exception handling is the best practice.
And every big application has to use exception handling.
Even in JAVA if u use streams or files , u have to use exception handling
Well you can use it........!!!
Here is an excellent codeproject article.
SUMMARY:
* Check it early
* Don't trust external data
* The only reliable devices are: the video, the mouse and keyboard.
* Writes can fail, too
* Don't throw new Exception()
* Don't put important exception information on the Message field
* Put a single catch (Exception ex) per thread
* Generic Exceptions caught should be published
* Log Exception.ToString(); never log only Exception.Message!
* Don't catch (Exception) more than once per thread
* Don't ever swallow exceptions
* Cleanup code should be put in finally blocks
* Use "using" everywhere
* Don't return special values on error conditions
* Don't use exceptions to indicate absence of a resource
* Don't use exception handling as means of returning information from a method
* Use exceptions for errors that should not be ignored
* Don't clear the stack trace when re-throwing an exception
* Avoid changing exceptions without adding semantic value
* Exceptions should be marked [Serializable]
* When in doubt, don't Assert, throw an Exception
* Each exception class should have at least the three original constructors
* Be careful when using the AppDomain.UnhandledException event
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.