Mixing
When should you create your own exception type?
Clash Royale CLAN TAG#URR8PPP
up vote
7
down vote
favorite
I am working on a project where we are restructuring old C code into new c++.
And for error handling, we are using exceptions. We are creating different exception types for different modules. But 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_excetpion and so on.
So while thinking about it I realized 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. If there is any such problematic approach that you have used, I would be happy to hear it and learn from it.
c++ exception exception-handling
asked 1 hour ago
Amit Bhaira
73741025
add a comment |Â
up vote
7
down vote
favorite
I am working on a project where we are restructuring old C code into new c++.
And for error handling, we are using exceptions. We are creating different exception types for different modules. But 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_excetpion and so on.
So while thinking about it I realized 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. If there is any such problematic approach that you have used, I would be happy to hear it and learn from it.
c++ exception exception-handling
asked 1 hour ago
Amit Bhaira
73741025
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago
add a comment |Â
up vote
7
down vote
favorite
up vote
7
down vote
favorite
I am working on a project where we are restructuring old C code into new c++.
And for error handling, we are using exceptions. We are creating different exception types for different modules. But 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_excetpion and so on.
So while thinking about it I realized 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. If there is any such problematic approach that you have used, I would be happy to hear it and learn from it.
c++ exception exception-handling
asked 1 hour ago
Amit Bhaira
73741025
I am working on a project where we are restructuring old C code into new c++.
And for error handling, we are using exceptions. We are creating different exception types for different modules. But 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_excetpion and so on.
So while thinking about it I realized 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. If there is any such problematic approach that you have used, I would be happy to hear it and learn from it.
c++ exception exception-handling
c++ exception exception-handling
asked 1 hour ago
Amit Bhaira
73741025
asked 1 hour ago
Amit Bhaira
73741025
asked 1 hour ago
Amit Bhaira
73741025
asked 1 hour ago
Amit Bhaira
73741025
asked 1 hour ago
Amit Bhaira
73741025
73741025
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago
add a comment |Â
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
4
down vote
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:
- A custom message for each case, making it more useful for reporting
- Catch can capture only the intended exceptions, more easily crashes on unexpected cases (yes, thats an advantage over incorrect handling)
- On crash, IDE can show the exception type, helping even more with debugging
answered 58 mins ago
JVApen
4,43011128
add a comment |Â
up vote
3
down vote
Create your own exception types when:
- you might want to differentiate them when handling. If they're different types, you have the option to write different
catchclauses. They should still have a common base so you can have common handling when that is appropriate - you want to add some specific structured data you can actually use in the handler
Having 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.
answered 1 hour ago
Useless
42.5k45193
add a comment |Â
up vote
1
down vote
I see two possible reasons.
1) If you want to store in the exception class some custom information about the exception, then you need an exception with extra data members. Often you will inherit from one of the std exception classes.
2) If you want to differentiate between exceptions. For instance suppose you have two distinct invalid argument situations and in your catch block you want to be able to differeentiate between the two. You can create two child classes of std::invalid_argument
answered 1 hour ago
Fabio
632315
add a comment |Â
up vote
1
down vote
The issue I see with each element of the STL firing a distinct memory exception is that some parts of the stl are built on others, so queue would have to catch and translate list exceptions, or clients of queue would have to know to handle list exceptions.
I can see some logic in separating the exceptions from different modules, but I can also see the logic of having a project-wide exception base class. I can also see the logic of having exception type classes.
The unholy alliance would be to build an exception hierarchy:
std::exception
EXProjectBase
EXModuleBase
EXModule1
EXModule2
EXClassBase
EXClassMemory
EXClassBadArg
EXClassDisconnect
EXClassTooSoon
EXClassTooLate
Then insist that every actual fired exception is derived from a module and an exception classification. Then, you can catch whatever makes sense to the catcher, such as a disconnection, rather than Having to separately catch HighLevelDisconnect and LowLevelDisconnect.
On the other hand it is also completely fair to suggest that The HighLevel interface should have completely dealt with LowLevel failures, and they should not be seen by the HighLevel client.
answered 8 mins ago
Gem Taylor
1,425115
add a comment |Â
up vote
0
down vote
I think that in addition to the reasons in other answers could be code readability, because a lot of time programmers spend supporting the code. Consider two pieces of code (assuming they throw "empty frame" error):
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw std::exception("Error: empty frame");
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw EmptyFrame();
In the second case I think it is more readable, and the message for the user (which printed with what() function) is hidden inside this custom exception class.
answered 24 mins ago
stackoverflower
6811
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
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:
- A custom message for each case, making it more useful for reporting
- Catch can capture only the intended exceptions, more easily crashes on unexpected cases (yes, thats an advantage over incorrect handling)
- On crash, IDE can show the exception type, helping even more with debugging
answered 58 mins ago
JVApen
4,43011128
add a comment |Â
up vote
4
down vote
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:
- A custom message for each case, making it more useful for reporting
- Catch can capture only the intended exceptions, more easily crashes on unexpected cases (yes, thats an advantage over incorrect handling)
- On crash, IDE can show the exception type, helping even more with debugging
answered 58 mins ago
JVApen
4,43011128
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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:
- A custom message for each case, making it more useful for reporting
- Catch can capture only the intended exceptions, more easily crashes on unexpected cases (yes, thats an advantage over incorrect handling)
- On crash, IDE can show the exception type, helping even more with debugging
answered 58 mins ago
JVApen
4,43011128
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:
- A custom message for each case, making it more useful for reporting
- Catch can capture only the intended exceptions, more easily crashes on unexpected cases (yes, thats an advantage over incorrect handling)
- On crash, IDE can show the exception type, helping even more with debugging
answered 58 mins ago
JVApen
4,43011128
answered 58 mins ago
JVApen
4,43011128
answered 58 mins ago
JVApen
4,43011128
answered 58 mins ago
JVApen
4,43011128
4,43011128
add a comment |Â
add a comment |Â
up vote
3
down vote
Create your own exception types when:
- you might want to differentiate them when handling. If they're different types, you have the option to write different
catchclauses. They should still have a common base so you can have common handling when that is appropriate - you want to add some specific structured data you can actually use in the handler
Having 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.
answered 1 hour ago
Useless
42.5k45193
add a comment |Â
up vote
3
down vote
Create your own exception types when:
- you might want to differentiate them when handling. If they're different types, you have the option to write different
catchclauses. They should still have a common base so you can have common handling when that is appropriate - you want to add some specific structured data you can actually use in the handler
Having 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.
answered 1 hour ago
Useless
42.5k45193
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Create your own exception types when:
- you might want to differentiate them when handling. If they're different types, you have the option to write different
catchclauses. They should still have a common base so you can have common handling when that is appropriate - you want to add some specific structured data you can actually use in the handler
Having 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.
answered 1 hour ago
Useless
42.5k45193
Create your own exception types when:
- you might want to differentiate them when handling. If they're different types, you have the option to write different
catchclauses. They should still have a common base so you can have common handling when that is appropriate - you want to add some specific structured data you can actually use in the handler
Having 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.
answered 1 hour ago
Useless
42.5k45193
answered 1 hour ago
Useless
42.5k45193
answered 1 hour ago
Useless
42.5k45193
answered 1 hour ago
Useless
42.5k45193
42.5k45193
add a comment |Â
add a comment |Â
up vote
1
down vote
I see two possible reasons.
1) If you want to store in the exception class some custom information about the exception, then you need an exception with extra data members. Often you will inherit from one of the std exception classes.
2) If you want to differentiate between exceptions. For instance suppose you have two distinct invalid argument situations and in your catch block you want to be able to differeentiate between the two. You can create two child classes of std::invalid_argument
answered 1 hour ago
Fabio
632315
add a comment |Â
up vote
1
down vote
I see two possible reasons.
1) If you want to store in the exception class some custom information about the exception, then you need an exception with extra data members. Often you will inherit from one of the std exception classes.
2) If you want to differentiate between exceptions. For instance suppose you have two distinct invalid argument situations and in your catch block you want to be able to differeentiate between the two. You can create two child classes of std::invalid_argument
answered 1 hour ago
Fabio
632315
add a comment |Â
up vote
1
down vote
up vote
1
down vote
I see two possible reasons.
1) If you want to store in the exception class some custom information about the exception, then you need an exception with extra data members. Often you will inherit from one of the std exception classes.
2) If you want to differentiate between exceptions. For instance suppose you have two distinct invalid argument situations and in your catch block you want to be able to differeentiate between the two. You can create two child classes of std::invalid_argument
answered 1 hour ago
Fabio
632315
I see two possible reasons.
1) If you want to store in the exception class some custom information about the exception, then you need an exception with extra data members. Often you will inherit from one of the std exception classes.
2) If you want to differentiate between exceptions. For instance suppose you have two distinct invalid argument situations and in your catch block you want to be able to differeentiate between the two. You can create two child classes of std::invalid_argument
answered 1 hour ago
Fabio
632315
answered 1 hour ago
Fabio
632315
answered 1 hour ago
Fabio
632315
answered 1 hour ago
Fabio
632315
632315
add a comment |Â
add a comment |Â
up vote
1
down vote
The issue I see with each element of the STL firing a distinct memory exception is that some parts of the stl are built on others, so queue would have to catch and translate list exceptions, or clients of queue would have to know to handle list exceptions.
I can see some logic in separating the exceptions from different modules, but I can also see the logic of having a project-wide exception base class. I can also see the logic of having exception type classes.
The unholy alliance would be to build an exception hierarchy:
std::exception
EXProjectBase
EXModuleBase
EXModule1
EXModule2
EXClassBase
EXClassMemory
EXClassBadArg
EXClassDisconnect
EXClassTooSoon
EXClassTooLate
Then insist that every actual fired exception is derived from a module and an exception classification. Then, you can catch whatever makes sense to the catcher, such as a disconnection, rather than Having to separately catch HighLevelDisconnect and LowLevelDisconnect.
On the other hand it is also completely fair to suggest that The HighLevel interface should have completely dealt with LowLevel failures, and they should not be seen by the HighLevel client.
answered 8 mins ago
Gem Taylor
1,425115
add a comment |Â
up vote
1
down vote
The issue I see with each element of the STL firing a distinct memory exception is that some parts of the stl are built on others, so queue would have to catch and translate list exceptions, or clients of queue would have to know to handle list exceptions.
I can see some logic in separating the exceptions from different modules, but I can also see the logic of having a project-wide exception base class. I can also see the logic of having exception type classes.
The unholy alliance would be to build an exception hierarchy:
std::exception
EXProjectBase
EXModuleBase
EXModule1
EXModule2
EXClassBase
EXClassMemory
EXClassBadArg
EXClassDisconnect
EXClassTooSoon
EXClassTooLate
Then insist that every actual fired exception is derived from a module and an exception classification. Then, you can catch whatever makes sense to the catcher, such as a disconnection, rather than Having to separately catch HighLevelDisconnect and LowLevelDisconnect.
On the other hand it is also completely fair to suggest that The HighLevel interface should have completely dealt with LowLevel failures, and they should not be seen by the HighLevel client.
answered 8 mins ago
Gem Taylor
1,425115
add a comment |Â
up vote
1
down vote
up vote
1
down vote
The issue I see with each element of the STL firing a distinct memory exception is that some parts of the stl are built on others, so queue would have to catch and translate list exceptions, or clients of queue would have to know to handle list exceptions.
I can see some logic in separating the exceptions from different modules, but I can also see the logic of having a project-wide exception base class. I can also see the logic of having exception type classes.
The unholy alliance would be to build an exception hierarchy:
std::exception
EXProjectBase
EXModuleBase
EXModule1
EXModule2
EXClassBase
EXClassMemory
EXClassBadArg
EXClassDisconnect
EXClassTooSoon
EXClassTooLate
Then insist that every actual fired exception is derived from a module and an exception classification. Then, you can catch whatever makes sense to the catcher, such as a disconnection, rather than Having to separately catch HighLevelDisconnect and LowLevelDisconnect.
On the other hand it is also completely fair to suggest that The HighLevel interface should have completely dealt with LowLevel failures, and they should not be seen by the HighLevel client.
answered 8 mins ago
Gem Taylor
1,425115
The issue I see with each element of the STL firing a distinct memory exception is that some parts of the stl are built on others, so queue would have to catch and translate list exceptions, or clients of queue would have to know to handle list exceptions.
I can see some logic in separating the exceptions from different modules, but I can also see the logic of having a project-wide exception base class. I can also see the logic of having exception type classes.
The unholy alliance would be to build an exception hierarchy:
std::exception
EXProjectBase
EXModuleBase
EXModule1
EXModule2
EXClassBase
EXClassMemory
EXClassBadArg
EXClassDisconnect
EXClassTooSoon
EXClassTooLate
Then insist that every actual fired exception is derived from a module and an exception classification. Then, you can catch whatever makes sense to the catcher, such as a disconnection, rather than Having to separately catch HighLevelDisconnect and LowLevelDisconnect.
On the other hand it is also completely fair to suggest that The HighLevel interface should have completely dealt with LowLevel failures, and they should not be seen by the HighLevel client.
answered 8 mins ago
Gem Taylor
1,425115
answered 8 mins ago
Gem Taylor
1,425115
answered 8 mins ago
Gem Taylor
1,425115
answered 8 mins ago
Gem Taylor
1,425115
1,425115
add a comment |Â
add a comment |Â
up vote
0
down vote
I think that in addition to the reasons in other answers could be code readability, because a lot of time programmers spend supporting the code. Consider two pieces of code (assuming they throw "empty frame" error):
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw std::exception("Error: empty frame");
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw EmptyFrame();
In the second case I think it is more readable, and the message for the user (which printed with what() function) is hidden inside this custom exception class.
answered 24 mins ago
stackoverflower
6811
add a comment |Â
up vote
0
down vote
I think that in addition to the reasons in other answers could be code readability, because a lot of time programmers spend supporting the code. Consider two pieces of code (assuming they throw "empty frame" error):
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw std::exception("Error: empty frame");
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw EmptyFrame();
In the second case I think it is more readable, and the message for the user (which printed with what() function) is hidden inside this custom exception class.
answered 24 mins ago
stackoverflower
6811
add a comment |Â
up vote
0
down vote
up vote
0
down vote
I think that in addition to the reasons in other answers could be code readability, because a lot of time programmers spend supporting the code. Consider two pieces of code (assuming they throw "empty frame" error):
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw std::exception("Error: empty frame");
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw EmptyFrame();
In the second case I think it is more readable, and the message for the user (which printed with what() function) is hidden inside this custom exception class.
answered 24 mins ago
stackoverflower
6811
I think that in addition to the reasons in other answers could be code readability, because a lot of time programmers spend supporting the code. Consider two pieces of code (assuming they throw "empty frame" error):
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw std::exception("Error: empty frame");
void MyClass::function() nothrow(false)
// ...
if (errorCondition)
throw EmptyFrame();
In the second case I think it is more readable, and the message for the user (which printed with what() function) is hidden inside this custom exception class.
answered 24 mins ago
stackoverflower
6811
edited 14 mins ago
answered 24 mins ago
stackoverflower
6811
answered 24 mins ago
stackoverflower
6811
answered 24 mins ago
stackoverflower
6811
6811
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52589224%2fwhen-should-you-create-your-own-exception-type%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Derive from exception and create custom exceptions; that is good for debugging because it helps the understanding of the code. Also, it gives a better overall structure
– Alberto Miola
1 hour ago
Idea is to have control. You catch the exceptions that your code rises, and you do only catches for those that you expect. This tells people who read your code which exceptions can happen here. If you catch some generic exception, it can come from anywhere, from your code, from dependencies, who knows, not the guy who looks at your code. If your reasoning not to do them is "it takes a full minute of my time", then rethink your reasoning. It's perfectly fine to derive them without adding anything, any functionality or the like. Just deriving them to be able to distinct them.
– Aziuth
39 mins ago
@Aziuth Then why there is a logical division of errors in std. And why only one bad_alloc. Why not list_bad_alloc, vector_bad_alloc. That is more descriptive. Isn't it?
– Amit Bhaira
32 mins ago