Menu
I am working on a project where we are restructuring old C code into new C++ where for error handling we are using exceptions.
We are creating different exception types for different modules.
I don't see it is worth but I don't have any valid argument to prove my point. So if we would have written the standard library, you would get to see vector_exception, list_exception and so on.
While thinking about it I stumbled upon this question:
When should you create your own exception type and when should you stick to the exceptions already created in std library?
Also, what could be the problems that we may face in the near future if we go by the above approach?
771
You should only implement a custom exception if it provides a benefit compared to Java's standard exceptions. The class name of your exception should end with Exception. If an API method specifies an exception, the exception class becomes part of the API, and you need to document it.
If you decide to define your own exception class. it must be a subclass of a Throwable class. You must decide which class you will extend. The two existing subclasses of Throwable are Exception and Error.
Since the client is unaware of the implementations of the interface and since they maybe can throw different exceptions, it's good place to create custom exceptions to uniformise the errors thrown.
If you need to throw an exception for an unrecoverable situation (in other words, you don't plan to catch and handle it), then do not create your own exception type. However, there are legitimate (though quite rare) cases where exceptions actually are used to signal recoverable exceptional circumstances.
In Java, we can create our own exceptions that are derived classes of the Exception class. Creating our own Exception is known as custom exception or user-defined exception.
Keep the following points in mind when writing our own exception classes All exceptions must be a child of Throwable. If we want to write a checked exception that is automatically enforced by the Handle or Declare Rule, we need to extend the Exception class. If we want to write a runtime exception, we need to extend the RuntimeException class.
4 best practices for custom exceptions. 1 1. Always provide a benefit. The previously described examples for additional attributes or methods showed the intention of a custom exception. It ... 2 2. Follow the naming convention. 3 3. Provide Javadoc comments for your exception class. 4 4. Provide a constructor that sets the cause.
All exceptions must be a child of Throwable. If we want to write a checked exception that is automatically enforced by the Handle or Declare Rule, we need to extend the Exception class. If we want to write a runtime exception, we need to extend the RuntimeException class. We can define our own Exception class as below:
Create your own exception types when:
catch clauses. They should still have a common base so you can have common handling when that is appropriateHaving separate list and vector exceptions doesn't seem worthwhile, unless there's something distinctively list-like or vectorish about them. Are you really going to have different catch handling depending on which type of container had an error?
Conversely it could make sense to have separate exception types for things that might be recoverable at runtime, versus things that are rolled-back but could be retried, versus things that are definitely fatal or indicate a bug.
197
Using the same exception everywhere is easy. Especially when trying to catch that exception. Unfortunately, it opens the door for Pokemon exception handling. It brings the risk of catching exceptions you don't expect.
Using a dedicated exception for all the different modules adds several advantages:
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
