-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use user-defined exceptions #244
Comments
For simplicity's sake I think it is much easier to deal with libs that have fewer rather than more different types of exceptions (as long as there isn't weird overlaps). So, here's a few suggestions on how that could be done:
These could be
Could be
Could be
Could be Anyways, this way there doesn't need to be this large tree of possible exceptions to keep in head if they are grouped a bit. |
I'd recommend that if you add multiple exception classes derived from any std::exception related class, that you have your own base class first, so that they can all be handled at once if the user desires. |
I started a feature branch for user-defined exceptions. There is now a class I shall replace more standard exceptions in the next days. I would be happy for comments! |
@whackashoe there are various reasons why we should add own exceptions. For example when you access a property that does not exist or is it invalid, you can throw an exception like The general error message that comes with |
@nlohmann I'm a new user of your library. Great job. There are couple of suggestions that I would like to make regarding exception handling. In the constructor of exception class, you prepend formatted error code to the exception message. Would you consider not doing that? Since this information is available in the exception handler, the user can decide whether to output the error code or not. Another suggestion that I would like to make is to avoid using string formatting in order to splice extra info in the error message. The reason is that once part of the message, this information cannot be accessed programmatically. In @markand's example above, given the missing property name, the user of the library can decide what info should flow upstream (e.g. message to the user), and how to format it. If the name of the property is part of the message, the user of the library has only two sub-optimal choices: avoid passing this information upstream, or displaying a message beyond user's control. Also in many cases this extra info in the exception itself is not really necessary: the info is already in scope where the exception should be handled. Last point, however, is arguable. Some people might say that it's okay to let the exception from this library ripple all the way to some high level exception handler where the specific type may not be known. Finally, one place where I fould some inspiration regarding exception handling is POCO. I think their solution is pretty neat and I would like to recommend you have a look. |
@krzysztofwos, thanks for the suggestions. Here are my thoughts:
|
I think that For example, my use case is a (surprise!) REST API. Any Regarding your last point, the idea is a bit too self-referential. I think that the content of an exception should be defined statically, and a JSON object certainly isn't. You can document all the properties that it would have, but then what if someone makes a typo accessing a property in the handler for |
As long as it's not due to an out of memory condition, then you should be okay with dynamic memory allocation. |
The user-defined exceptions are done now, see the new feature branch. This branch also contains the option to switch off assertions (#296). |
This is really cool to see, do you have any idea when you would be merging this in? |
Not really. There are still 1-2 issues that need to be fixed before I can start with the 3.0.0 release. |
This issue is nearly complete. If anyone would like to have a look at the soon-to-be-merged state, please have a look at branch https://github.com/nlohmann/json/tree/feature/exceptions_3.0.0. It contains user-defined exceptions, and only the documentation needs some final touches. |
- If an overflow occurs during parsing a number from a JSON text, an exception (std::out_of_range for the moment, to be replaced by a user-defined exception #244) is thrown so that the overflow is detected early and roundtripping is guaranteed. - NaN and INF floating-point values can be stored in a JSON value and are not replaced by null. That is, the basic_json class behaves like double in this regard (no exception occurs). However, NaN and INF are serialized to “null”. - Adjusted test cases appropriately.
Merged this feature into |
After a small survey on Reddit it seems to be a good idea to replace the standard exceptions used in the library right now with user-defined exceptions.
The motivations for this are:
In the course of this ticket, the list of currently used exceptions need to be classified into user-defined exception classes:
Furthermore, STL exceptions need to be caught and rethrown as user-defined exception in several cases.
The text was updated successfully, but these errors were encountered: