My rule of thumb is if I CAN recover from an exception, then I need to ensure that my application can recover. It's not exactly rocket science. I believe the key is to ensure that you never throw a generic exception. Each exception that you throw needs to be specific to the issue or problem at hand. That way you catch that specific exception and not a similar exception from lower level classes. You also never want to handle a generic exception, either. Sometimes you won't be able to recover from a specific exception and so it's perfectly fine to let it get deferred to a higher level class to handle it correctly.
The balance comes when you're at the highest level and you're getting exceptions that were thrown levels down. You may not be able to catch all of them, because you may not know what exceptions were not handled in the levels below. In .NET it's really easy to send your department information when an unhandled exception occurs. It's not the best way and it may not always be the right way, but sometimes it's the only way to properly find out what type of exceptions are being thrown. I'd rather have the application crash then to have my end user using an application where the state is unknown. This can lead to more problems and issues.
Software development is something you craft and with time you'll be able to learn and generate better exception handlers. Don't throw generic exceptions and don't handle generic exceptions, because if it's generic then you have no idea what really happened. Leaving an end user with the ability to do more damage is NEVER the way to go.
This information will be very helpful for me. offshore software development
ReplyDeleteI really like this stuff dear. Windows Thin Client & Citrix Thin Client
ReplyDelete