Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #5622 > unrolled thread

need argument for try catch blocks

Back to article view | Back to comp.lang.c++

Contents

  need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-05-26 08:20 -0700
    Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-26 18:24 +0200
      Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-05-26 10:28 -0700
        Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-05-26 10:31 -0700
        Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-26 20:36 +0200
          Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-05-27 06:10 -0700
            Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-06 04:24 -0500
          Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-06 05:22 -0500
            Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-06 21:53 -0700
              Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-06 23:48 -0700
                Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-07 00:18 -0700
              Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 07:13 -0500
                Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-07 07:33 -0700
                  Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 10:08 -0500
                    Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 10:12 -0500
                      Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-07 13:59 -0700
                        Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 16:48 -0500
                          Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 18:20 -0500
                    Re: need argument for try catch blocks Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-07 14:42 -0700
                      Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 18:13 -0500
                        Re: need argument for try catch blocks Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-07 16:21 -0700
                          Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-07 19:13 -0500
                        Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-08 07:07 -0500
                          Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-08 07:12 -0500
                            Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-09 07:19 -0500
                              Re: need argument for try catch blocks "io_x" <a@b.c.invalid> - 2011-06-09 21:00 +0200
                          Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-08 15:40 -0500
                            Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-08 16:07 -0500
                            Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-09 10:21 -0500
    Re: need argument for try catch blocks Juha Nieminen <nospam@thanks.invalid> - 2011-05-27 06:40 +0000
    Re: need argument for try catch blocks Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-27 14:05 +0200
      Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-27 14:16 +0200
        Re: need argument for try catch blocks Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-27 14:48 +0200
          Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-27 15:10 +0200
            Re: need argument for try catch blocks Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-27 15:54 +0200
              Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-27 16:13 +0200
            Re: need argument for try catch blocks "Fred Zwarts" <F.Zwarts@KVI.nl> - 2011-05-30 09:56 +0200
              Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-30 10:22 +0200
        Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-05-27 07:43 -0700
          Re: need argument for try catch blocks Paavo Helde <myfirstname@osa.pri.ee> - 2011-05-27 10:19 -0500
          Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-05-27 17:58 +0200
            Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-05-30 09:43 -0700
              Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-05-30 11:58 -0700
              Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-05-31 08:57 -0700
                Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-05-31 13:33 -0700
                  Re: need argument for try catch blocks Ian Collins <ian-news@hotmail.com> - 2011-06-01 09:03 +1200
                    Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-05-31 14:57 -0700
                      Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-06-01 02:06 +0200
                    Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-05-31 16:32 -0700
                  Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-06-01 11:42 -0700
                    Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-06-02 16:01 -0700
                    Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-03 04:27 -0700
                      Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-06-03 07:39 -0700
                        Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-03 10:43 -0700
                        Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-06-03 11:31 -0700
                          Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-06-03 12:14 -0700
                            Re: need argument for try catch blocks Leigh Johnston <leigh@i42.co.uk> - 2011-06-03 21:22 +0100
                            Re: need argument for try catch blocks "Balog Pal" <pasa@lib.hu> - 2011-06-04 17:30 +0200
                              Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-06-04 15:16 -0700
                            Re: need argument for try catch blocks Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-11 10:22 +0000
                          Re: need argument for try catch blocks Edek <edek.pienkowski@gmail.com> - 2011-06-03 21:17 +0200
                            Re: need argument for try catch blocks Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-03 18:24 -0700
                              Re: need argument for try catch blocks Edek <edek.pienkowski@gmail.com> - 2011-06-04 19:34 +0200
                                Re: need argument for try catch blocks Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-04 19:39 -0700
                            Re: need argument for try catch blocks Keith H Duggar <duggar@alum.mit.edu> - 2011-06-04 07:22 -0700
                            Re: need argument for try catch blocks Edek <edek.pienkowski@gmail.com> - 2011-06-04 19:24 +0200
                      Re: need argument for try catch blocks Christopher <cpisz@austin.rr.com> - 2011-06-03 07:51 -0700
                        Re: need argument for try catch blocks "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-03 20:57 +0200
                        Re: need argument for try catch blocks Dombo <dombo@disposable.invalid> - 2011-06-05 13:29 +0200
          Re: need argument for try catch blocks Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-27 19:01 +0200
            Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-05-31 17:13 -0700
              Re: need argument for try catch blocks Edek <edek.pienkowski@gmail.com> - 2011-06-03 16:04 +0200
                Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-03 09:44 -0700
                  Re: need argument for try catch blocks Edek <edek.pienkowski@gmail.com> - 2011-06-03 19:04 +0200
                    Re: need argument for try catch blocks Öö Tiib <ootiib@hot.ee> - 2011-06-04 07:05 -0700
        Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-06 05:15 -0500
    Re: need argument for try catch blocks "MikeP" <mp011011@some.org> - 2011-06-06 04:43 -0500

Page 4 of 4 — ← Prev page 1 2 3 [4]

#6155

> RAII is a paradigm quite unique to C++ and orthogonal to OOP.
> Indeed, most if not all OO programming languages do not even
> support RAII.

OT: What about the with-construct in Python?

with file.open(...) as f:
     ....
     .... any block leave calls f's cleanup func, closing file
     ....

Looks like RAII to me.

>
>> Regardless, C-style programming implies neither of these.
>
> And "C-style" has nothing to do with your problems. Your problems
> are with "crap C++ code" and frustration.
>
>> You are both also talking as if I am introducing the exceptions. Nay!
>> I am trying to handle them! Someone else was responsible for throwing
>> exceptions left and right from c-style code that had a disregard for
>> freeing of resources.
>
> No, that is simply crap /C++/ code and entirely understandable
> frustration with it.

I kind of don't really understand why this frustration leads very often
to being a Best Practises Prophet coupled with blaming everyone around.
Isn't the situation just working with legacy software,
not even crappy one, just the windowz API is such, and other
parts of it remember the old times, and newer parts are written in a
different way and so on, and maybe the "C-Style" colleague is really
just aware of the fact that the software does not rewrite itself?
(don't say this is off-topic - just a different aspect)

> Instead,
> why don't you just rant about "crap code" (which everyone would
> get behind) and leave your colleague and C out of it?

Because that would be more difficult thing to do? :-) Having some
notion of OOP/OOA/RAII/whatever makes one feel soo much better. Calling
code 'crappy' helps too (maybe it is crappy, how can I know).

I also heard macros are really really evil, take MAX(a++), who has not
heard about this one? Never use macros ;-)

[toc] | [prev] | [next] | [standalone]

#6162

On Jun 3, 12:17 pm, Edek <edek.pienkow...@gmail.com> wrote:
> > RAII is a paradigm quite unique to C++ and orthogonal to OOP.
> > Indeed, most if not all OO programming languages do not even
> > support RAII.
>
> OT: What about the with-construct in Python?
>
> with file.open(...) as f:
>      ....
>      .... any block leave calls f's cleanup func, closing file
>      ....
>
> Looks like RAII to me.

It's a poor man's RAII. It's functionally equivalent to a finally
block, but at least all the relevant code is in one spot as opposed to
spread out with a "try { ... } finally {}". However, the problem with
both is that ownership is not always restricted to a particular stack
scope.

I'd rather not get into a definitional war over RAII, but this highly
related concept which I'm about to explain, if not RAII itself, is
relatively unique to C++ as far as I know. It is very related to the
concept of ownership. The C++ way, either RAII or very related to
RAII, is to code in such a way that all objects always have an owner,
a clear and identifiable condition that will release that resource
when it's no longer needed. This ownership relationship forms an
ownership graph, which when properly done is acyclic. It usually has
(most of) its roots (or leaves if you prefer it that way) in objects
on the stack. The beauty and utility of this approach is that you no
longer have to worry about almost all resource collection on error
paths, including thrown exception code flow paths. The implicit
calling of functions on stack exit, which in turn cause the implicit
calling of other functions, and so on, allow us to quite neatly clean
up resources.

If you code to this idiom, it becomes exceptionally difficult to
accidentally "leak" something, /and much more importantly/ if you do
detect a leak, it becomes much easier to reason about where the bug
is. Find out where that object lost being owned and fix it. It allows
you to much more easily reason about code correctness in isolation
from other code.

This implicit calling of functions on stack exit, and for sub-objects,
is relatively unique to C++ as far as I know.

Is it syntactic sugar? In one sense, insofaras all higher level
concepts are to some degree syntactic sugar over assembly. Does its
use lead to a far better quality code than without, given the same
"man hours"? I would argue yes.

[toc] | [prev] | [next] | [standalone]

#6205

> If you code to this idiom, it becomes exceptionally difficult to
> accidentally "leak" something, /and much more importantly/ if you do
> detect a leak, it becomes much easier to reason about where the bug
> is. Find out where that object lost being owned and fix it. It allows
> you to much more easily reason about code correctness in isolation
> from other code.
>
> This implicit calling of functions on stack exit, and for sub-objects,
> is relatively unique to C++ as far as I know.
>

I do agree with almost everything you wrote, expect one thing:
reasoning about it is certainly easy, when things are consistent
and the people involved are on the same page.

> This ownership relationship forms an
> ownership graph, which when properly done is acyclic.

If one could find a solution that would allow cycles without GC...
That's probably the only thing I don't
like about sharing resources or building arbitrary structures. One can
argue this is not that bad in most cases, when this can be handled by
weak references, by avoiding cycles, or by cleaning up (candidate for
RAII style itself).

[toc] | [prev] | [next] | [standalone]

#6224

On Jun 4, 10:34 am, Edek <edek.pienkow...@gmail.com> wrote:
> > If you code to this idiom, it becomes exceptionally difficult to
> > accidentally "leak" something, /and much more importantly/ if you do
> > detect a leak, it becomes much easier to reason about where the bug
> > is. Find out where that object lost being owned and fix it. It allows
> > you to much more easily reason about code correctness in isolation
> > from other code.
>
> > This implicit calling of functions on stack exit, and for sub-objects,
> > is relatively unique to C++ as far as I know.
>
> I do agree with almost everything you wrote, expect one thing:
> reasoning about it is certainly easy, when things are consistent
> and the people involved are on the same page.

Agreed. Perhaps I was a bit too strong. It's no silver bullet. It
requires a fair share of active concern from the programmer at all
times, unlike the standard "allocate and forget" of GC. It's very
useful when used correctly, and does little to help if used
incorrectly or not at all.

[toc] | [prev] | [next] | [standalone]

#6200

On Jun 3, 3:17†pm, Edek <edek.pienkow...@gmail.com> wrote:
> > RAII is a paradigm quite unique to C++ and orthogonal to OOP.
> > Indeed, most if not all OO programming languages do not even
> > support RAII.
>
> OT: What about the with-construct in Python?
>
> with file.open(...) as f:
> † † †....
> † † †.... any block leave calls f's cleanup func, closing file
> † † †....
>
> Looks like RAII to me.

It is a very limited/restricted form of RAII, yes. For example,
this form of RAII is not usable when the resource is accessed by
more than one function. Unfortunately the __del__ methods do not
reliably provide more general RAII either (as one discovers soon
after running their Python program on Jython).

Anyhow, it's always interesting (and I imagine highly satisfying
for some) to watch such languages evolve /towards/ C++. The more
vociferously anti-C++ the language's users are, the more ironic
and amusing is the evolution.

> >> Regardless, C-style programming implies neither of these.
>
> > And "C-style" has nothing to do with your problems. Your problems
> > are with "crap C++ code" and frustration.
>
> >> You are both also talking as if I am introducing the exceptions. Nay!
> >> I am trying to handle them! Someone else was responsible for throwing
> >> exceptions left and right from c-style code that had a disregard for
> >> freeing of resources.
>
> > No, that is simply crap /C++/ code and entirely understandable
> > frustration with it.
>
> I kind of don't really understand why this frustration leads very often
> to being a Best Practises Prophet coupled with blaming everyone around.

Indeed Christopher's reaction to his work is very common. In my
opinion it stems from a basic frustration at seeing code making
/known/ and in principle /preventable/ mistakes.

Furthermore, not only are these preventable mistakes costing the
company time and money, but, you as the maintainer are forced to
dive head first into the warped and twisted tangle of crap code.
You are forced to comprehend it, to read it again and again, to
discover its darkest hidden corners, to run it, to test it, and
Llort forbid /reproduce/ it's quirks in new code!

In short, you are forced to wallow in and drink from a cesspool
that in your mind should never have been created.

> Isn't the situation just working with legacy software, not even
> crappy one, just the windowz API is such, and other parts of it
> remember the old times, and newer parts are written in a different
> way and so on, and maybe the "C-Style" colleague is really just
> aware of the fact that the software does not rewrite itself?
> (don't say this is off-topic - just a different aspect)

Precisely! That perspective is the key to rising above the gut
emotional reaction and regaining control. The key realization
is that all of us are performing with /finite/ resources (time,
talent, discipline, health, money, etc) impinged by reality. (1)

> > Instead,
> > why don't you just rant about "crap code" (which everyone would
> > get behind) and leave your colleague and C out of it?
>
> Because that would be more difficult thing to do? :-) Having some
> notion of OOP/OOA/RAII/whatever makes one feel soo much better. Calling
> code 'crappy' helps too (maybe it is crappy, how can I know).

Indeed people always want to feel better about themselves and it
seems bashing others is a natural way to achieve this. I'm trying
to help Christopher /realize/ that he is doing this so that he
can rise above his current emotional limitations and mature as a
professional.

> I also heard macros are really really evil, take MAX(a++),
> who has not heard about this one? Never use macros ;-)

Yes MAX is an example where C++ would /not/ use a macro given
that C++ offers superior solutions for that case. However, at
this time macros remain an /at times necessary/ evil in C++.

KHD

(1) as an example of finite self-control and mental health, Leigh
Johnston is physiologically incapable of choosing not to respond
to trolls directed at him. See the thread rooted here:

   http://groups.google.com/group/comp.lang.c++/msg/c007296f3c169cca

[toc] | [prev] | [next] | [standalone]

#6203

On 06/04/2011 03:01 AM, Stefan Ram wrote:
> Edek<edek.pienkowski@gmail.com>  writes:
>> OT: What about the with-construct in Python?
>> with file.open(...) as f:
>> Looks like RAII to me.
>
>    This »with« was used in Common Lisp much earlier. I would
>    not call it »RAII«.
>
>    Here is one attempt to implement something like that in C:
>

[code]

>    Ok, the double return code is somewhat ugly, but this is
>    just a draft to convey the idea. Also, one would pass an
>    additional data structure with client data through the
>    callback functions.
>

Powers of two are really wicked in this case; I think they don't add up,
in this draft, but that was not the point. I don't program in C much,
but as far I know one can write a lot of things which are really
object oriented in plain C, using such twisted concepts, macros for
example, to get any data structures and flowas. The concepts one gets
are more important that the uglyness of implementation - usage counts.

Edek

[toc] | [prev] | [next] | [standalone]

#6143

On Jun 3, 6:27 am, Öö Tiib <oot...@hot.ee> wrote:
> On Jun 1, 9:42 pm, Christopher <cp...@austin.rr.com> wrote:
> How you can gain (or restore?) your reputation? I have one idea: It is
> lack of unit tests that often causes masses of unexpected work in
> projects with large rapidly changing code-base. Do you know some
> script language? Doesn't matter, these take a weekend to learn anyway.
> Go write some scripts that generate unit test stubs for your code
> base. Then make tests. Don't forget to test exception safety. When
> there are unit tests then it is lot less likely that someone writes
> something and breaks it (whatever style he uses). So team mates will
> hopefully see you as useful again.- Hide quoted text -

I didn't realize my entire team was reading this thread and my
reputation could be ruined by one simple question! I don't have a
reputation to ruin on my team. My team is neither involved in this
discussion or its outcome. While they may by happenstance wander onto
this newsgroup, chances are slim. If they do, I don't mind. I haven't
written any code here yet, so there is nothing for me to design or
test. I am fixing the mess that existed before my joining. At the day
of my hire, I was handed the source code for a windows service that
will not even start up 9 times out of 10, because of one unhandled
exception or another. 3 months of handling them one by one and they
continue to appear. When it does start up, it runs for all of an hour
or two before crashing. I am hardly worried about my reputation at
this point. I am worried about fixing the source of the problems and I
think that source is in someone's thinking rather than in the code.

At any rate, the question has already been answered. Boundries need to
be identified and catching and handling needs to occur there. I am
happy with that.

[toc] | [prev] | [next] | [standalone]

#6151

* Christopher, on 03.06.2011 16:51:
>
> At the day
> of my hire, I was handed the source code for a windows service that
> will not even start up 9 times out of 10, because of one unhandled
> exception or another. 3 months of handling them one by one and they
> continue to appear. When it does start up, it runs for all of an hour
> or two before crashing.

Ditch that code.


Cheers & hth.,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#6237

Op 03-Jun-11 16:51, Christopher schreef:

> At the day of my hire, I was handed the source code for a windows service that
> will not even start up 9 times out of 10, because of one unhandled
> exception or another.

If that is your problem, why don't you install a structured exception 
handler (SEH - Windows feature not standard C++) and dump the stack when 
the handler is called? That way you know exactly which exception was 
thrown from where and fix the problem at the source rather than 
polluting the code with unnecessary catch blocks to hide the problem.

[toc] | [prev] | [next] | [standalone]

#5713

On 05/27/2011 04:43 PM, Christopher wrote:

> I'd love to be counting on destructors. So far though, I'd say 60% of
> the code is written in C-style, with global pointers being to things
> allocated in various class methods, released in others, global
> instances being used left and right, macros, etc. etc. Things are just
> not well contained. There are classes where the functionality is
> partly handled by global functions and partly handled by class
> methods. But, I am ranting.
>
> My point is though, out here, at least in my city and for several jobs
> now, there always seems to be that c-style programmer on the team that
> does this kind of thing ruining or at least making it difficult to
> follow most of the OO principles. They are usually well respected with
> seniority too. Things get into such a mess that I don't know where to
> start fixing it. I wish I could just mind control someone and convince
> them to follow S.O.L.I.D principles, RAII, and several other things.
>
> Anyway, the advice in the posts is good. You guys have changed my mind
> on exception handling. Maybe I will try to convice my team that we
> should take the time to come up with a design decision on when and how
> to handle exceptions, their types, identify these boundries, etc.

If 60% of code is C (or C-style), I wouldn't be orthodox about RAII. 
Either the developers do have ways to handle debugging and so on, maybe 
just slightly home-made, or maybe some ways can be gradually introduced.

Edek

[toc] | [prev] | [next] | [standalone]

#5933

On May 27, 8:01 pm, Edek <edek.pieITAKNIECZY...@gmail.com> wrote:
> On 05/27/2011 04:43 PM, Christopher wrote:
>
>
>
>
>
> > I'd love to be counting on destructors. So far though, I'd say 60% of
> > the code is written in C-style, with global pointers being to things
> > allocated in various class methods, released in others, global
> > instances being used left and right, macros, etc. etc. Things are just
> > not well contained. There are classes where the functionality is
> > partly handled by global functions and partly handled by class
> > methods. But, I am ranting.
>
> > My point is though, out here, at least in my city and for several jobs
> > now, there always seems to be that c-style programmer on the team that
> > does this kind of thing ruining or at least making it difficult to
> > follow most of the OO principles. They are usually well respected with
> > seniority too. Things get into such a mess that I don't know where to
> > start fixing it. I wish I could just mind control someone and convince
> > them to follow S.O.L.I.D principles, RAII, and several other things.
>
> > Anyway, the advice in the posts is good. You guys have changed my mind
> > on exception handling. Maybe I will try to convice my team that we
> > should take the time to come up with a design decision on when and how
> > to handle exceptions, their types, identify these boundries, etc.
>
> If 60% of code is C (or C-style), I wouldn't be orthodox about RAII.
> Either the developers do have ways to handle debugging and so on, maybe
> just slightly home-made, or maybe some ways can be gradually introduced.

If your code does throw exceptions (or calls modules that throw
exceptions out) then it is not a C anymore and so you have to go
orthodox about exception safety and RAII. Similarly if your code runs
multiple threads then you have to go orthodox about thread safety.

Attempts to ignore usage principles of tools used will result with
disaster. If you doubt then better go work in saw-mill. Few fingers
later you will learn to follow the principles of saw usage. ;)

[toc] | [prev] | [next] | [standalone]

#6140

>>> Anyway, the advice in the posts is good. You guys have changed my mind
>>> on exception handling. Maybe I will try to convice my team that we
>>> should take the time to come up with a design decision on when and how
>>> to handle exceptions, their types, identify these boundries, etc.
>>
>> If 60% of code is C (or C-style), I wouldn't be orthodox about RAII.
>> Either the developers do have ways to handle debugging and so on, maybe
>> just slightly home-made, or maybe some ways can be gradually introduced.
>
> If your code does throw exceptions (or calls modules that throw
> exceptions out) then it is not a C anymore and so you have to go
> orthodox about exception safety and RAII. Similarly if your code runs
> multiple threads then you have to go orthodox about thread safety.

Exception safety does not necessarily require RAII. It depends,
case-by-case. Sometimes, one can mix large parts of code which is
too expensive to 'convert' to RAII with wrapping code that RAIIfies it.

I agree that RAII, or close to RAII, would be a reasonable goal: what
I'm saying is that does not happen in a glimpse and you have to live
those couple of months/years plus bug fixing with non-RAII code.

Do you know a QuickRAIIFierTool download page? :-) I'm half-serious,
one should write code transformation tools such as this one.

>
> Attempts to ignore usage principles of tools used will result with
> disaster. If you doubt then better go work in saw-mill. Few fingers
> later you will learn to follow the principles of saw usage. ;)

I must learn to use this metaphor...

[toc] | [prev] | [next] | [standalone]

#6145

On Jun 3, 5:04 pm, Edek <edek.pienkow...@gmail.com> wrote:
>
> Exception safety does not necessarily require RAII. It depends,
> case-by-case. Sometimes, one can mix large parts of code which is
> too expensive to 'convert' to RAII with wrapping code that RAIIfies it.

If exceptions are thrown by code that is called by such "too
expensive" then it is thrower who has to be converted into non-thrower
by wrapper. I don't get how it can be other way around.

> I agree that RAII, or close to RAII, would be a reasonable goal: what
> I'm saying is that does not happen in a glimpse and you have to live
> those couple of months/years plus bug fixing with non-RAII code.
>
> Do you know a QuickRAIIFierTool download page? :-) I'm half-serious,
> one should write code transformation tools such as this one.

No i don't know. Overall there is rather sad set of C++ refactoring
and round-trip engineering tools available. Sad even if to include
commercial ones. The ones that are available are often expensive but
still must be applied carefully to not damage more than cure.

Also be careful when considering writing your own tool. Usually every
team contains a dedicated tool-dwarf or couple, but tools that
outright refactor source code are made rarely.

Typical problems are that the C++ itself is most complex programming
language in use, source material is always defective, an human is
involved in configuring and assisting the tool but may make mistakes
and tool itself is also likely defective (or with "softer"
terminology: inflexible, too mechanical and not enough self-
critical).

The C++ code base should be therefore covered with unit tests rather
well first for any sort of refactoring to be applied to it at low pain
level.

[toc] | [prev] | [next] | [standalone]

#6146

>
>> I agree that RAII, or close to RAII, would be a reasonable goal: what
>> I'm saying is that does not happen in a glimpse and you have to live
>> those couple of months/years plus bug fixing with non-RAII code.
>>
>> Do you know a QuickRAIIFierTool download page? :-) I'm half-serious,
>> one should write code transformation tools such as this one.
>
> No i don't know. Overall there is rather sad set of C++ refactoring
> and round-trip engineering tools available. Sad even if to include
> commercial ones. The ones that are available are often expensive but
> still must be applied carefully to not damage more than cure.
>
> Also be careful when considering writing your own tool. Usually every
> team contains a dedicated tool-dwarf or couple, but tools that
> outright refactor source code are made rarely.
>

Just to clear the possibility: the team I'm with doesn't need one.

I'm rather considering this as a 'make money' option in some distant
future (read: probably never)

> Typical problems are that the C++ itself is most complex programming
> language in use, source material is always defective, an human is
> involved in configuring and assisting the tool but may make mistakes
> and tool itself is also likely defective (or with "softer"
> terminology: inflexible, too mechanical and not enough self-
> critical).

Yeah. I always prefer even to indent the code myself than rely on an
automata, maybe the IDE is helping more than it is annoying. And most
source analysis tools for me are more of a pastime that an everyday
tool.

The first thing I thought of when thinking about how to write such tools
is that C++ is indeed complex to parse, let alone transform.
I don't agree with the defective argument: most simple refactoring
mechanisms built into IDEs fall back to 'Preview' allowing human
intervention, either when the tool is not sure or just for the sake
of checking.

>
> The C++ code base should be therefore covered with unit tests rather
> well first for any sort of refactoring to be applied to it at low pain
> level.

Actually, I always consider refactoring more an obstruction to doing
unit tests (or the other way round...);
I do agree that having unit tests vastly helps when doing ANY
changes.

[toc] | [prev] | [next] | [standalone]

#6199

On Jun 3, 8:04 pm, Edek <edek.pienkow...@gmail.com> wrote:
>
> > Also be careful when considering writing your own tool. Usually every
> > team contains a dedicated tool-dwarf or couple, but tools that
> > outright refactor source code are made rarely.
>
> Just to clear the possibility: the team I'm with doesn't need one.
>
> I'm rather considering this as a 'make money' option in some distant
> future (read: probably never)

Yes, likely never since there are always better opportunities of
making some money. Devs buy them rarely if not integrated into IDE
(and IDE is also often downloaded and not bought). Some manager may
buy something but manager has to buy from Rational or Intel or
MicroSoft or Apple or Oracle or IBM (not you). Otherwise competing
manager can accuse him of buying crappy and unreliable tools from Edek
as reason that causes the projects to fail.

>
> ...
>
> The first thing I thought of when thinking about how to write such tools
> is that C++ is indeed complex to parse, let alone transform.
> I don't agree with the defective argument: most simple refactoring
> mechanisms built into IDEs fall back to 'Preview' allowing human
> intervention, either when the tool is not sure or just for the sake
> of checking.

Yes, i did try to soften "defective". The simple things you describe
are usually self-critical enough. That does not mean they are
sufficiently flexible (configurable) or context-aware. On lot of cases
the resulting code does not compile. Even if it does compile it is
highly likely that you have to further edit it (for example move
#include or member function declaration added by tool to correct
place).

> > The C++ code base should be therefore covered with unit tests rather
> > well first for any sort of refactoring to be applied to it at low pain
> > level.
>
> Actually, I always consider refactoring more an obstruction to doing
> unit tests (or the other way round...);
> I do agree that having unit tests vastly helps when doing ANY
> changes.

I don't understand the obstruction i see only pure aid. Unit test
helps refactorer to see if he broke a contract of a class or a
function. If he broke then that means on worst case few hours of his
to repair the things. If there are no unit tests it may mean
cooperatively several man months of work time plus frustrated
customers thanks to his "refactoring".

[toc] | [prev] | [next] | [standalone]

#6280

Balog Pal wrote:
> "Edek" <edek.pieITAKNIECZYTAM@gmail.com>
>> If they do anything that is necessary or of value, they should be
>> there. Naturally, the project formal/informal policy is one thing to
>> follow, but in general such 'extra' try-catches are done for example:
>>
>> a) to clean up resources (like DB, if destructors are not enough),
>> then they are necessary
>
> Hell no. Resources must be handler by RAII, and never left to hang
> around "raw". And mandatory release code must not be multiplicated at
> every possible exit.

While RAII is the suggested C++ style, using exceptions to facilitate 
clean up is not prohibited. RAII is not the only way that clean-up can be 
done. Your use of 'must' is incorrect. 'should' would have been a better 
word to use.

[toc] | [prev] | [next] | [standalone]

#6279

Stefan Ram wrote:
> Christopher <cpisz@austin.rr.com> writes:

>> My point of view is that when your dealing with a huge project with
>> poor documentation, it is better to always surround anything that
>> throws with a try catch block, even if it seems unecessary.
>
>  This is exacly what exceptions were invented to prevent.

No. Exceptions cannot PREVENT that coding style, so therefore, exceptions 
were not invented to PREVENT that (or else they would have been shelved 
as a miserable failure against that requirement).

The solution the OP is looking for is how to create exception-safe code. 
He should be worried about his code and not the other code. His code 
needs to be robust in the case of exception from the other code and he 
needs to be aware of the exceptions the other code throws (what something 
can throw is part of knowing how to use the library). Wrapping calls in 
try blocks is decidedly not the C++ idiomatic way of doing that (not that 
catching to clean up, rather than handle, must absolutely never be used 
though).

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c++

csiph-web