Why is it a "bad idea" to throw your own exceptions?

Question

Why is it a "bad idea" to throw your own exceptions?

found here

Lubbock

Where did you read this? – Brunhilda

It's not. Who said it was? – Visigoth

It's a very good idea to throw your own exceptions! :) – Runion

Interview question - trick question? – Lubbock

I think that question is worded a bit poorly. – Lamdin

That question on the link provided is asking you to think about exceptions and when user defined exceptions may not be suitable - it's open-ended not asking you for a definitive yes/no answer IMO – Roberson

It's poorly crafted question, without any references or details on what conclusion raised such question. Shall we vote to close? – Catamount

I'm not surprised at all that it comes from a recruiting site. Typical headhunter question... all bluster, no clue. – Rillis

It could be a trick question. But, more likely it's just extremely poorly worded. I would think twice about joining a company that asks idiotic questions like this. – Submaxillary

As others said, poorly worded question – Ha

Answer 1

In general, it is perfectly fine to throw your own exceptions. Perhaps what you meant to ask was "When is it not necessarily a good idea to throw my own exception?"

One case is when you should be throwing a standard exception. For example, if your method takes a file name and is supposed to return a file, you should probably throw your platform's standard FileNotFoundException rather than throw PeanutPowersFileNotFoundException. If you really want to throw your own exception, you should probably have it extend the standard FileNotFoundException.

Update: Bloch explains this in Item 60 of Effective Java

Lamdin

Answer 2

It's not. You should create and throw custom exceptions whenever you have an exceptional situation.

Brunhilda

I think you should avoid creating a custom exception whenever there is an appropriate(!) exception in your language to help users of your library catch similar exceptional conditions in similar ways. – Affidavit

@Affidavit - custom exception may mean a subtype of std::exception in C++ for instance, what allows client to deal with it in unified way – Catamount

@DerMike,I agree with you, a dev should use existing exceptions when they apply. – Brunhilda

Answer 3

It isn't provided they are derived from whatever the standard base exception type is (std::exception in c++, or Exception in python, etc...)

If they _aren't_derived from the normal base type, then other people may not catch them when they are expecting to catch all exceptions - which would be a bad thing.

Borrego

Answer 4

It's not wrong to create your own exception type. However, before going through creating your own, you should check whether your framework already provides an exception that fits.

From the .Net design guidelines:

Consider throwing existing exceptions residing in the System namespaces instead of creating custom exception types.

Do create and throw custom exceptions if you have an error condition that can be programmatically handled in a different way than any other existing exceptions. Otherwise, throw one of the existing exceptions.

Do not create and throw new exceptions just to have your team's exception.

Paella

That may be what Microsoft said when designing .net, but I don't agree. If a DLL file isn't found, which would be more useful: FileNotFoundException, or DllCouldntLoadException? The latter might usefully have a derived DllFileNotFoundException, but generally it's more useful to know what the system was trying to do when something happened, than to know what type of error occurred. – Sal

Answer 5

I believe you might be asking why is it a bad idea to re-throw exceptions.

By "rethrow", I mean catching an exception and than generating a new one and throwing it. This can be problematic, as you could end up consuming the original stack trace and loosing all context of the error.

Submaxillary

If you do it right, you do not. In .NET it means rethrowing it with the rethrow statement (no parameters) – Trituration

fair enough. I don't do .NET, so this is outside my mental scope. Thanks for the interesting tidbit though. – Submaxillary

Answer 6

You should not invent your own type of Exception, unless you have something extra you want to add to the Exception type.

If you want to tell the user of your API that they have provided an invalid argument, you should throw an ArgumentException, but if your library fails because of some library specific reason, that you can't convey in a regular exception, you should roll your own and let it contain the info the developer needs.

Counterchange

Answer 7

To continue Peter's response another case when throwing an exception is not a good idea is if you use throwing exceptions to control the business logic of your program.

As long as the exception you are throwing is derived from a proper object, and conveys just that - exceptional situation, throwing an exception is totally acceptable.

Using throwing exceptions to control business logic in addition to being a bad design pattern has also performance implications - throwing and catching exceptions is rather expensive as compared to branching based on the results returned from the method

Trituration

Answer 8

There's nothing wrong with creating your own exceptions, which can be tailored to convey exactly the information which is appropriate for your situation. A ConfigFileNotFoundException conveys more information than a FileNotFoundException (which file didn't we find?).

But, by all means, make sure that you catch and handle each and every custom exception inside of your code. When the exception flies to some place outside your module (call it package, call it namespace), those folks out there will not even know that it exists, much less what to do with it. Except for a catch (Throwable t) {/* whut? */}.

Zacynthus

Answer 9

To me it seems that the question is to catch inexperienced candidates trying to fake experience. There's nothing wrong about throwing your own exceptions in my opinion, and as you can see to everyone else that answered here.

Sage

Answer 10

It's not a bad idea at all. If an exceptional situation arises, an exception should be thrown to handle it, especially if you're designing code that others may use, may receive bad input, etc.

It is a bad idea to use exceptions where they're not absolutely necessary, such as situations that are recoverable by normal checks in code or as part of normal execution, since they do have a lot of overhead associated with them. I imagine that's where you may have gotten the idea that they're a bad idea in general. But for what they're meant to do (flagging an exceptional situation that your code isn't equipped to handle), they're absolutely the best tool.

And if you do create custom exceptions for code others might use, do document what they are and what they mean. That way later users of your code will know that they're possible and what they mean if they arise, and can handle them appropriately.

Wolfgang