Exceptional GitLab maintenance is scheduled for June 24, 2025. The service will be unavailable between 8:00 am and 9:30 am. Please do not work on the platform until an announcement indicates that maintenance is complete.
"If your code is huge, knowing the exception itself is not enough, if this exception may be thrown from several locations in your code. To identify where the exception was thrown, I use the `__FILE__` and `__LINE__` macro which gives the file and line where they were found in the code (better alternative `std::source_location` is present in C++ 20 but is unfortunately [not well supported yet](https://en.cppreference.com/w/cpp/compiler_support)).\n",
"If your code is huge, knowing the exception itself is not enough, if this exception may be thrown from several locations in your code. To identify where the exception was thrown, I used for a long time the `__FILE__` and `__LINE__` macro which gives the file and line where they were found in the code.\n",
"\n",
"So my constructor looks like:\n",
"So my constructor looked like:\n",
"\n",
"````\n",
"```c++\n",
"HomemadeException(const std::string& msg, const char* invoking_file, int invoking_line);\n",
"````\n",
"```\n",
"\n",
"It might be a bit wordy but:\n",
"* It's safe.\n",
"* Print is correct.\n",
"* It is easy to figure out where it happened.\n",
"\n",
"A better alternative named `std::source_location` was introduced in C++ 20, but it took some time (circa 2023) to be supported properly by both libc++ and libstdc++ (and even currently using libc++ some features don't exactly work [as printed on the can](https://en.cppreference.com/w/cpp/utility/source_location)...)\n",
"Here is a transcript of my own exception class, which may be found in [my main project](https://gitlab.inria.fr/MoReFEM/CoreLibrary/MoReFEM/tree/master/Sources/Utilities/Exceptions). Namespace has ben removed (you should add one if you intend to use it in practice):\n",
...
...
@@ -119,82 +128,90 @@
"metadata": {},
"outputs": [],
"source": [
"#include <string>\n",
"#include <exception>\n",
"\n",
"/*!\n",
" * \\brief Generic class for MoReFEM exceptions.\n",
" */\n",
"class Exception: public std::exception\n",
"{\n",
"public:\n",
"\n",
" /// \\name Special members.\n",
" ///@{\n",
"// Doesn't work on Xeus-cling: C++ 20 on board!\n",
"\n",
" /*!\n",
" * \\brief Constructor with simple message.\n",
" *\n",
" * \\param[in] msg Message.\n",
" * \\param[in] invoking_file File that invoked the function or class; usually __FILE__.\n",
" * \\param[in] invoking_line File that invoked the function or class; usually __LINE__.\n",
" */\n",
"\n",
" //@}\n",
" explicit Exception(const std::string& msg, const char* invoking_file, int invoking_line);\n",
"If you read [the documentation](https://en.cppreference.com/w/cpp/utility/source_location), we should be able to completely avoid the explicit `std::source_location::current()` call at calling site, according to [CppReference](https://en.cppreference.com/w/cpp/utility/source_location/current):\n",
"\n",
"> If current() is used in a default argument, the return value corresponds to the location of the call to current() at the call site.\n",
"\n",
"That is unfortunately not the behaviour I have observed with libc++ on macOS: the file and line returned is the one from the header file, hence the explicit argument at calling site. Likewise, `function_name()` is empty, hence the test in my `SetWhat()` message.\n",
"\n",
"Nonetheless, we may hope these glitches will be solved at some point, and even with them `std::source_location` is more comfy to use than `__FILE__` and `__LINE__` C macros."
]
},
{
"cell_type": "markdown",
"metadata": {},
...
...
%% Cell type:markdown id: tags:
# [Getting started in C++](./) - [Home-made exception class](./HomemadeException.ipynb)
%% Cell type:markdown id: tags:
<h1>Table of contents<spanclass="tocSkip"></span></h1>
<divclass="toc"><ulclass="toc-item"><li><span><ahref="#Why-an-home-made-exception-class?"data-toc-modified-id="Why-an-home-made-exception-class?-1">Why an home-made exception class?</a></span><ulclass="toc-item"><li><span><ahref="#Clunky-constructors-provided-in-std::exception"data-toc-modified-id="Clunky-constructors-provided-in-std::exception-1.1">Clunky constructors provided in <code>std::exception</code></a></span></li><li><span><ahref="#std::string-for-storage"data-toc-modified-id="std::string-for-storage-1.2"><code>std::string</code> for storage</a></span></li><li><span><ahref="#Indicating-the-file-and-line"data-toc-modified-id="Indicating-the-file-and-line-1.3">Indicating the file and line</a></span></li></ul></li><li><span><ahref="#Implementation-of-my-home-made-class"data-toc-modified-id="Implementation-of-my-home-made-class-2">Implementation of my home-made class</a></span><ulclass="toc-item"><li><span><ahref="#Exception.hpp"data-toc-modified-id="Exception.hpp-2.1">Exception.hpp</a></span></li><li><span><ahref="#Exception.cpp"data-toc-modified-id="Exception.cpp-2.2">Exception.cpp</a></span></li><li><span><ahref="#Call-to-use-the-exception-class"data-toc-modified-id="Call-to-use-the-exception-class-2.3">Call to use the exception class</a></span></li></ul></li></ul></div>
%% Cell type:markdown id: tags:
## Why an home-made exception class?
### Clunky constructors provided in `std::exception`
`std::exception` provides two constructors: a copy one and a default one without arguments. The idea is that you should provide your own derived exception class for each exception in your program, for which you would override properly the `what()` virtual method to display the adequate message.
I prefer to provide a simple way to provide on spot exception with a mere constructor, to be able to write something like:
```c++
doublex=-3.;
if(x<-2.||x>5.)
throwHomemadeException("x should be in [-2., 5.]");
```
rather than much more verbosy:
%% Cell type:code id: tags:
``` C++17
#include <exception>
class RangeMinus2PlusFiveException : public std::exception
I'm not comfortable either with the `char*` type for the `what` message, especially if you want to tailor it to provide as many information as possible to the end-user (here for instance providing the value of `x` that triggered the exception is much better).
With `char*`, you might encounter rather easily two opposites issues:
- The memory could leak if not properly deallocated.
- On the contrary, if it was somehow released and the exception `what()` is asked later along the line you might end-up with garbage characters in part of your string, as the memory freed might have been used for something else.
We already saw the patch to avoid this kind of issues: using a container with proper RAII ensured. `std::string`is the most obvious choice for a text message.
So in my code I derive my exceptions from a homemade class which is itself derived from `std::exception`; the main difference is that the storage is done with a `std::string` and the override of the `what()` method reads this `std::string`.
### Indicating the file and line
If your code is huge, knowing the exception itself is not enough, if this exception may be thrown from several locations in your code. To identify where the exception was thrown, I use the `__FILE__` and `__LINE__` macro which gives the file and line where they were found in the code (better alternative `std::source_location` is present in C++ 20 but is unfortunately [not well supported yet](https://en.cppreference.com/w/cpp/compiler_support)).
If your code is huge, knowing the exception itself is not enough, if this exception may be thrown from several locations in your code. To identify where the exception was thrown, I used for a long time the `__FILE__` and `__LINE__` macro which gives the file and line where they were found in the code.
A better alternative named `std::source_location` was introduced in C++ 20, but it took some time (circa 2023) to be supported properly by both libc++ and libstdc++ (and even currently using libc++ some features don't exactly work [as printed on the can](https://en.cppreference.com/w/cpp/utility/source_location)...)
Here is a transcript of my own exception class, which may be found in [my main project](https://gitlab.inria.fr/MoReFEM/CoreLibrary/MoReFEM/tree/master/Sources/Utilities/Exceptions). Namespace has ben removed (you should add one if you intend to use it in practice):
### Exception.hpp
%% Cell type:code id: tags:
``` C++17
#include <string>
#include <exception>
/*!
* \brief Generic class for MoReFEM exceptions.
*/
class Exception: public std::exception
{
public:
/// \name Special members.
///@{
/*!
* \brief Constructor with simple message.
*
* \param[in] msg Message.
* \param[in] invoking_file File that invoked the function or class; usually __FILE__.
* \param[in] invoking_line File that invoked the function or class; usually __LINE__.
*/
//@}
explicit Exception(const std::string& msg, const char* invoking_file, int invoking_line);
If you read [the documentation](https://en.cppreference.com/w/cpp/utility/source_location), we should be able to completely avoid the explicit `std::source_location::current()` call at calling site, according to [CppReference](https://en.cppreference.com/w/cpp/utility/source_location/current):
> If current() is used in a default argument, the return value corresponds to the location of the call to current() at the call site.
That is unfortunately not the behaviour I have observed with libc++ on macOS: the file and line returned is the one from the header file, hence the explicit argument at calling site. Likewise, `function_name()` is empty, hence the test in my `SetWhat()` message.
Nonetheless, we may hope these glitches will be solved at some point, and even with them `std::source_location` is more comfy to use than `__FILE__` and `__LINE__` C macros.
