When and Why I should Explicitly throw an Exception

I'm just trying to make my understanding of Exception mechanism more clear.

If something goes wrong when an app is executed, the runtime automatically throws an appropriate exception. If it is so, then why I should sometimes make some check and explicitly throw a specific exception?

How to identify such cases (when an exception should be explicitly thrown in code)?

I don't put any example here on purpose, becau开发者_如何学Cse I'd like to get a general understanding of the throwing exceptions approach.

I think the general approach should be Fail Fast - you want to identify and handle invalid program conditions as soon as possible, this would mean not just when a particular input is needed within your program logic but as soon as you "receive" this input (which could be way earlier in time and/or lines of codes).

For i.e. public methods that means validating an input first, and if appropriate throw an exception if the input violates what your method expects.

Generally, my rule is that if an error occurs that the code I'm writing can't specifically handle, I'll throw an exception. For instance, if I'm writing a function that accepts a couple of arguments, and the function is meaningless if the arguments are null I'll check for that and throw some ArgumentNullException's

Generally, a method, subroutine, component, service, or system should throw an exception only when that thing cannot do (successfully complete) whatever it was asked to do.

"whatever it was asked to do" is somewhat subjective, of course. As an example, if you have a method in a utility library that is named SaveFile() and it fails to save the file, but you called it from a client that is attempting to save a file to a location that might or might exist, and the client app doesn't even care if the file gets saved or not... Then the utility library SaveFile() method should still throw an exception, and the client should swallow it in the place where it was called.

I don't know that I could express the exhaustive list, but a few good examples might include

1. When you need to stop/alter execution for a scenario that wouldn't cause any system exceptions (if there are no foos with n bars the system is in trouble, throw a custom exception)

2. When you are at a boundary where the system exception would include data that was not needed, or possibly not desirable to expose (users my not need to see everything in the stack trace, but you could log the actual exception then throw a custom exception (Data Access, Service Access, etc) that allows you to control what is propagated downstream.

3. When you can add additional contextual information to an exception, i.e. you caught some exception and can use it as the inner exception for a new exception that includes information that can be useful for logging/debugging etc.

You can throw exceptions whenever your application enters any exceptional state. There may be invariants violated ("x can never be null!" is a good invariant which may be covered by an assertion or exception). Maybe something went terribly wrong, e.g. another machine sent corrupt data. Of course everything would result in some exception or error of the runtime of your choice (java, .net), but whenever your custom exception would be more concise (closer to the line of code which caused the problem, better naming, ...) than the built-in one, it's a possible candidate for a custom exception.

Theres another reason for custom exceptions: If all of your exceptions would inherit from a custom exception class, it's easier for the client to catch the exceptions he's interested in. Most of the time nobody wants to catch NPEs or stuff like that, so it may be more convenient to catch a smaller range of exceptions.

every method has a return type (whether that type be void, int, string, car, etc.) an exception allows you to return a message to a calling context that is NOT of type T, but is of Type Exception that says "something went wrong". What went wrong is identify by the derived type (from exception, as SQLException) and message. This creates a uniform interface (by type exception) for messaging errors.