On Wed, 2018-03-28 at 22:50 +0200, Christophe de Dinechin wrote:
> > On 28 Mar 2018, at 22:32, Christophe de Dinechin > om> wrote:
> >
> >
> >
> > > On 28 Mar 2018, at 20:46, Jonathon Jongsma
> > > wrote:
> > >
> > > On Wed, 2018-03-28 at 17:42 +0200, Christophe de Dinechin wrote:
> > > > Som
On Wed, Mar 28, 2018 at 05:35:35PM +0200, Christophe de Dinechin wrote:
> > On 28 Mar 2018, at 17:04, Christophe Fergeau wrote:
> > The part I'm missing is how you extract this limited number of full
> > strings that we'll need to translate into a po file (or equivalent). Is
> > there a tool which
> On 7 Mar 2018, at 12:51, Christophe Fergeau wrote:
>
> On Wed, Mar 07, 2018 at 12:28:57PM +0100, Christophe de Dinechin wrote:
>>> This behaviour seems inconsistent with std::runtime_error(const char *)
>>> which as far as I can tell does not have this lifetime expectation.
>>
>> You are cor
> On 28 Mar 2018, at 22:32, Christophe de Dinechin wrote:
>
>
>
>> On 28 Mar 2018, at 20:46, Jonathon Jongsma wrote:
>>
>> On Wed, 2018-03-28 at 17:42 +0200, Christophe de Dinechin wrote:
>>> Somewhat OT, but hopefully informative in the context of this thread.
>>>
>>>
On 26 Mar 2018
> On 28 Mar 2018, at 20:46, Jonathon Jongsma wrote:
>
> On Wed, 2018-03-28 at 17:42 +0200, Christophe de Dinechin wrote:
>> Somewhat OT, but hopefully informative in the context of this thread.
>>
>>
>>> On 26 Mar 2018, at 18:24, Jonathon Jongsma
>>> wrote:
>>>
>>> As teuf mentioned in a di
On Wed, 2018-03-28 at 17:42 +0200, Christophe de Dinechin wrote:
> Somewhat OT, but hopefully informative in the context of this thread.
>
>
> > On 26 Mar 2018, at 18:24, Jonathon Jongsma
> > wrote:
> >
> > As teuf mentioned in a different email, std::runtime_error in C++11
> > has a const char
Somewhat OT, but hopefully informative in the context of this thread.
> On 26 Mar 2018, at 18:24, Jonathon Jongsma wrote:
>
> As teuf mentioned in a different email, std::runtime_error in C++11 has a
> const char* constructor:
Since the presence of this constructor was used repeatedly as an a
> On 28 Mar 2018, at 17:04, Christophe Fergeau wrote:
>
> On Wed, Mar 28, 2018 at 02:44:56PM +0200, Christophe de Dinechin wrote:
>> In my proposal, that message is built in format_message with something like:
>>
>> int written = snprintf(buffer, size, "%s writing %s for file ‘%s'",
>> w
On Wed, Mar 28, 2018 at 02:44:56PM +0200, Christophe de Dinechin wrote:
> In my proposal, that message is built in format_message with something like:
>
> int written = snprintf(buffer, size, "%s writing %s for file ‘%s'",
> what(), operation, filename.c_str());
> return append_strerr
> On 28 Mar 2018, at 13:12, Christophe Fergeau wrote:
>
>> Do you have something against requiring string constants in English for our
>> error messages?
>>
>> Is it so difficult to understand that if I have:
>>
>> WriteError(“can’t write”, “header”, filename)
>> WriteError(“can’t
> Do you have something against requiring string constants in English for our
> error messages?
>
> Is it so difficult to understand that if I have:
>
> WriteError(“can’t write”, “header”, filename)
> WriteError(“can’t write”, “boson”, filename)
>
> I can localize all the combinatio
> On 26 Mar 2018, at 18:24, Jonathon Jongsma wrote:
>
> On Mon, 2018-03-26 at 12:36 +0200, Christophe de Dinechin wrote:
>> I realize I had left this one unanswered.
>>
>>> On 7 Mar 2018, at 15:14, Jonathon Jongsma
>>> wrote:
>>>
>>> On Wed, 2018-03-07 at 12:34 +0100, Christophe de Dinechin
On Mon, 2018-03-26 at 12:36 +0200, Christophe de Dinechin wrote:
> I realize I had left this one unanswered.
>
> > On 7 Mar 2018, at 15:14, Jonathon Jongsma
> > wrote:
> >
> > On Wed, 2018-03-07 at 12:34 +0100, Christophe de Dinechin wrote:
> > > > On 6 Mar 2018, at 17:47, Jonathon Jongsma
> >
I realize I had left this one unanswered.
> On 7 Mar 2018, at 15:14, Jonathon Jongsma wrote:
>
> On Wed, 2018-03-07 at 12:34 +0100, Christophe de Dinechin wrote:
>>> On 6 Mar 2018, at 17:47, Jonathon Jongsma
>>> wrote:
>>>
>>> On Tue, 2018-03-06 at 11:02 +0100, Christophe Fergeau wrote:
O
On Thu, Mar 08, 2018 at 10:56:55AM +0100, Christophe de Dinechin wrote:
> > In many cases you want to add information to the exception and
> > is quite common to catch one exception, add another informations
> > and throw a more detailed exception.
>
> It is useful, indeed. And when you need to do
> On 7 Mar 2018, at 12:52, Frediano Ziglio wrote:
>
>>> On 2 Mar 2018, at 18:13, Christophe Fergeau wrote:
>>>
>>> On Fri, Mar 02, 2018 at 02:00:23PM +0100, Christophe de Dinechin wrote:
> On 2 Mar 2018, at 09:03, Frediano Ziglio wrote:
>
>>>
>>> On 1 Mar 2018,
On Wed, 2018-03-07 at 12:34 +0100, Christophe de Dinechin wrote:
> > On 6 Mar 2018, at 17:47, Jonathon Jongsma
> > wrote:
> >
> > On Tue, 2018-03-06 at 11:02 +0100, Christophe Fergeau wrote:
> > > On Fri, Mar 02, 2018 at 06:06:32PM +0100, Christophe de Dinechin
> > > wrote:
> > > > > FWIW, I also
On Wed, Mar 07, 2018 at 12:28:57PM +0100, Christophe de Dinechin wrote:
> > This behaviour seems inconsistent with std::runtime_error(const char *)
> > which as far as I can tell does not have this lifetime expectation.
>
> You are correct, but please note that std::runtime_error takes a string as
> > On 2 Mar 2018, at 18:13, Christophe Fergeau wrote:
> >
> > On Fri, Mar 02, 2018 at 02:00:23PM +0100, Christophe de Dinechin wrote:
> >>
> >>
> >>> On 2 Mar 2018, at 09:03, Frediano Ziglio wrote:
> >>>
> >
> > On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
> >
> >>
> >
> On 6 Mar 2018, at 17:47, Jonathon Jongsma wrote:
>
> On Tue, 2018-03-06 at 11:02 +0100, Christophe Fergeau wrote:
>> On Fri, Mar 02, 2018 at 06:06:32PM +0100, Christophe de Dinechin
>> wrote:
FWIW, I also find myself in agreement with Frediano and Lukas on
this point.
>>>
>>> OK. M
> On 2 Mar 2018, at 18:13, Christophe Fergeau wrote:
>
> On Fri, Mar 02, 2018 at 02:00:23PM +0100, Christophe de Dinechin wrote:
>>
>>
>>> On 2 Mar 2018, at 09:03, Frediano Ziglio wrote:
>>>
>
> On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
>
>>
>> From: Christophe
On Tue, 2018-03-06 at 11:02 +0100, Christophe Fergeau wrote:
> On Fri, Mar 02, 2018 at 06:06:32PM +0100, Christophe de Dinechin
> wrote:
> > > FWIW, I also find myself in agreement with Frediano and Lukas on
> > > this point.
> >
> > OK. Maybe I misunderstood something.
> >
> > Do we agree that t
On Fri, Mar 02, 2018 at 06:06:32PM +0100, Christophe de Dinechin wrote:
> > FWIW, I also find myself in agreement with Frediano and Lukas on this point.
>
> OK. Maybe I misunderstood something.
>
> Do we agree that the case Frediano raised is someone trying:
>
> throw Error(“The value of “
On Fri, Mar 02, 2018 at 02:00:23PM +0100, Christophe de Dinechin wrote:
>
>
> > On 2 Mar 2018, at 09:03, Frediano Ziglio wrote:
> >
> >>>
> >>> On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
> >>>
>
> From: Christophe de Dinechin
>
> Throwing 'runtime_error' directly
> On 2 Mar 2018, at 17:16, Jonathon Jongsma wrote:
>
> On Fri, 2018-03-02 at 11:53 +0100, Lukáš Hrázký wrote:
>> On Fri, 2018-03-02 at 03:03 -0500, Frediano Ziglio wrote:
> On 1 Mar 2018, at 13:13, Frediano Ziglio
> wrote:
>
>>
>> From: Christophe de Dinechin
>
On Fri, 2018-03-02 at 11:53 +0100, Lukáš Hrázký wrote:
> On Fri, 2018-03-02 at 03:03 -0500, Frediano Ziglio wrote:
> > >
> > > > On 1 Mar 2018, at 13:13, Frediano Ziglio
> > > > wrote:
> > > >
> > > > >
> > > > > From: Christophe de Dinechin
> > > > >
> > > > > Throwing 'runtime_error' direct
> On 2 Mar 2018, at 11:53, Lukáš Hrázký wrote:
>
> On Fri, 2018-03-02 at 03:03 -0500, Frediano Ziglio wrote:
>>>
On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
>
> From: Christophe de Dinechin
>
> Throwing 'runtime_error' directly should be reserved for the supp
> On 2 Mar 2018, at 09:03, Frediano Ziglio wrote:
>
>>>
>>> On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
>>>
From: Christophe de Dinechin
Throwing 'runtime_error' directly should be reserved for the support
library. Add an 'Error' class as a base class for all
On Fri, 2018-03-02 at 03:03 -0500, Frediano Ziglio wrote:
> >
> > > On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
> > >
> > > >
> > > > From: Christophe de Dinechin
> > > >
> > > > Throwing 'runtime_error' directly should be reserved for the support
> > > > library. Add an 'Error' class as
>
> > On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
> >
> >>
> >> From: Christophe de Dinechin
> >>
> >> Throwing 'runtime_error' directly should be reserved for the support
> >> library. Add an 'Error' class as a base class for all errors thrown
> >> by the streaming agent, as well as sub
> On 1 Mar 2018, at 15:46, Lukáš Hrázký wrote:
>
> On Thu, 2018-03-01 at 12:40 +0100, Lukáš Hrázký wrote:
>> On Wed, 2018-02-28 at 16:43 +0100, Christophe de Dinechin wrote:
>>> From: Christophe de Dinechin
>>>
>>> Throwing 'runtime_error' directly should be reserved for the support
>>> libra
> On 1 Mar 2018, at 13:13, Frediano Ziglio wrote:
>
>>
>> From: Christophe de Dinechin
>>
>> Throwing 'runtime_error' directly should be reserved for the support
>> library. Add an 'Error' class as a base class for all errors thrown
>> by the streaming agent, as well as subclasses used to d
> On 1 Mar 2018, at 12:40, Lukáš Hrázký wrote:
>
> On Wed, 2018-02-28 at 16:43 +0100, Christophe de Dinechin wrote:
>> From: Christophe de Dinechin
>>
>> Throwing 'runtime_error' directly should be reserved for the support
>> library. Add an 'Error' class as a base class for all errors throw
> On 28 Feb 2018, at 17:46, Christophe Fergeau wrote:
>
> On Wed, Feb 28, 2018 at 04:43:15PM +0100, Christophe de Dinechin wrote:
>> From: Christophe de Dinechin
>>
>> Throwing 'runtime_error' directly should be reserved for the support
>> library. Add an 'Error' class as a base class for al
On Thu, 2018-03-01 at 12:40 +0100, Lukáš Hrázký wrote:
> On Wed, 2018-02-28 at 16:43 +0100, Christophe de Dinechin wrote:
> > From: Christophe de Dinechin
> >
> > Throwing 'runtime_error' directly should be reserved for the support
> > library. Add an 'Error' class as a base class for all errors
>
> From: Christophe de Dinechin
>
> Throwing 'runtime_error' directly should be reserved for the support
> library. Add an 'Error' class as a base class for all errors thrown
> by the streaming agent, as well as subclasses used to discriminate
> between categories of error.
>
> The Error clas
On Wed, 2018-02-28 at 16:43 +0100, Christophe de Dinechin wrote:
> From: Christophe de Dinechin
>
> Throwing 'runtime_error' directly should be reserved for the support
> library. Add an 'Error' class as a base class for all errors thrown
> by the streaming agent, as well as subclasses used to d
On Wed, Feb 28, 2018 at 04:43:15PM +0100, Christophe de Dinechin wrote:
> From: Christophe de Dinechin
>
> Throwing 'runtime_error' directly should be reserved for the support
> library. Add an 'Error' class as a base class for all errors thrown
> by the streaming agent, as well as subclasses us
From: Christophe de Dinechin
Throwing 'runtime_error' directly should be reserved for the support
library. Add an 'Error' class as a base class for all errors thrown
by the streaming agent, as well as subclasses used to discriminate
between categories of error.
The Error class offers:
- a 'form
39 matches
Mail list logo
