Patch to improve error messages

[Øyvind Harboe]

This patch stops CDT from sensoring error the underlying error message.

E.g. file not found would be replaced by some nonsensical cryptic
generic message.


Consider this a "patch & commit" ping :-)

--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[John Cortell]

Can you explain how to reproduce the problem. If
I remove the executable of a simple project
before launching a debug session, I get an error
dialog that needs improved grammar, but isn't
completely nonsensical or cryptic (see attached
screenshot). I assume your scenario is different.
It's important to provide reproducibility steps
when you submit a patch (if possible; sometimes,
a bug can be seen with a particular backend but
not the standard gnu/cygwin ones.

And of course, the formal process is to create a bugzilla report.

John

At 06:48 AM 3/31/2008, Øyvind Harboe wrote:
>This patch stops CDT from sensoring error the underlying error message.
>
>E.g. file not found would be replaced by some nonsensical cryptic
>generic message.
>
>
>Consider this a "patch & commit" ping :-)
>
>--
>Øyvind Harboe
>http://www.zylin.com - eCos ARM & FPGA developer kit
>
>Content-Type: text/plain; name=donotsensorerrormessage.txt
>X-Attachment-Id: f_fegz85vl0
>Content-Disposition: attachment; filename=donotsensorerrormessage.txt
>
>_______________________________________________
>cdt-debug-dev mailing list
>cdt-debug-dev-j9T/***@public.gmane.org
>https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

[Øyvind Harboe]

Hi John,

excuse my ignorance, but are you a committer?

> Can you explain how to reproduce the problem. If
> I remove the executable of a simple project
> before launching a debug session, I get an error
> dialog that needs improved grammar, but isn't
> completely nonsensical or cryptic (see attached
> screenshot). I assume your scenario is different.
> It's important to provide reproducibility steps
> when you submit a patch (if possible; sometimes,
> a bug can be seen with a particular backend but
> not the standard gnu/cygwin ones.

Are you in agreement that, fundamentally, error messages
should be propagated and not anonymized?

> And of course, the formal process is to create a bugzilla report.

I've tried that for lots of patches through the years. I'm trying something
a bit different this time to see if I have any better luck. It's an experiment
if you will.



--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[John Cortell]

At 12:28 PM 3/31/2008, Øyvind Harboe wrote:
>Hi John,
>
>excuse my ignorance, but are you a committer?

I am.

> > Can you explain how to reproduce the problem. If
> > I remove the executable of a simple project
> > before launching a debug session, I get an error
> > dialog that needs improved grammar, but isn't
> > completely nonsensical or cryptic (see attached
> > screenshot). I assume your scenario is different.
> > It's important to provide reproducibility steps
> > when you submit a patch (if possible; sometimes,
> > a bug can be seen with a particular backend but
> > not the standard gnu/cygwin ones.
>
>Are you in agreement that, fundamentally, error messages
>should be propagated and not anonymized?

I am.


> > And of course, the formal process is to create a bugzilla report.
>
>I've tried that for lots of patches through the years. I'm trying something
>a bit different this time to see if I have any better luck. It's an experiment
>if you will.

I'm not sure you're going to have much success
since ultimately someone should be opening a
bugzilla report. All you're doing is making more work for committers

Interestingly, you didn't supply the key piece of
information I requested. Reproducibility steps.

John

[Øyvind Harboe]

On Mon, Mar 31, 2008 at 7:52 PM, John Cortell
<john.cortell-***@public.gmane.org> wrote:
> At 12:28 PM 3/31/2008, Øyvind Harboe wrote:
> >Hi John,
> >
> >excuse my ignorance, but are you a committer?
>
> I am.
>
>
> > > Can you explain how to reproduce the problem. If
> > > I remove the executable of a simple project
> > > before launching a debug session, I get an error
> > > dialog that needs improved grammar, but isn't
> > > completely nonsensical or cryptic (see attached
> > > screenshot). I assume your scenario is different.
> > > It's important to provide reproducibility steps
> > > when you submit a patch (if possible; sometimes,
> > > a bug can be seen with a particular backend but
> > > not the standard gnu/cygwin ones.
> >
> >Are you in agreement that, fundamentally, error messages
> >should be propagated and not anonymized?
>
> I am.
>
>
>
> > > And of course, the formal process is to create a bugzilla report.
> >
> >I've tried that for lots of patches through the years. I'm trying something
> >a bit different this time to see if I have any better luck. It's an experiment
> >if you will.
>
> I'm not sure you're going to have much success
> since ultimately someone should be opening a
> bugzilla report. All you're doing is making more work for committers
>
> Interestingly, you didn't supply the key piece of
> information I requested. Reproducibility steps.

I understand from the above that you agree that it has been determined
that this is broken by inspection(and some cursory testing).

Surely it's not necessary to reproducability steps any more than
e.g. fresh regression testing cases for code that it is agreed is
broken by inspection?

I'll open a bugzilla report for this problem if there is consensus that
this should be fixed and that it can be agreed upon that it is broken.

In terms of testcase/reproducability, I'd go for a JUnit(or equivalent) test
for something like this. I don't know how to formulate such a test.




--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[John Cortell]

> > >I've tried that for lots of patches through the years. I'm
> trying something
> > >a bit different this time to see if I have any better luck.
> It's an experiment
> > >if you will.
> >
> > I'm not sure you're going to have much success
> > since ultimately someone should be opening a
> > bugzilla report. All you're doing is making more work for committers
> >
> > Interestingly, you didn't supply the key piece of
> > information I requested. Reproducibility steps.
>
>I understand from the above that you agree that it has been determined
>that this is broken by inspection(and some cursory testing).
>
>Surely it's not necessary to reproducability steps any more than
>e.g. fresh regression testing cases for code that it is agreed is
>broken by inspection?
>
>I'll open a bugzilla report for this problem if there is consensus that
>this should be fixed and that it can be agreed upon that it is broken.
>
>In terms of testcase/reproducability, I'd go for a JUnit(or equivalent) test
>for something like this. I don't know how to formulate such a test.

I very rarely change code based purely on inspection. I like to see
something fail before I go fix it, especially if it's something
reported by someone else...even if it looks obvious. I'm assuming you
found this not by code inspection by actually seeing a nondescript
error message surface. If you did, and it can be reproduced with a
standard gdb/mi session, telling me what those steps are will make
things easier for me. Otherwise, I have to go rig the code to
manufacture the scenario I think you're having.

John

[Øyvind Harboe]

> I very rarely change code based purely on inspection. I like to see
> something fail before I go fix it, especially if it's something
> reported by someone else...even if it looks obvious. I'm assuming you
> found this not by code inspection by actually seeing a nondescript
> error message surface. If you did, and it can be reproduced with a
> standard gdb/mi session, telling me what those steps are will make
> things easier for me. Otherwise, I have to go rig the code to
> manufacture the scenario I think you're having.

Since CDT is something that plugins can build on,
I'm sure that this is a familiar problem: you can't exercise
all your code paths using CDT alone.

As I recall this problem *can* happen with normal CDT, but it
becomes severe w/e.g. the Zylin Embedded CDT plugin. The Zylin Embedded
CDT pushes error handling into GDB as much as possible as GDB
is capable of a lot more than CDT really knows about w.r.t. what file
formats are supported, whether files are really required for to debug, etc.

I don't expect the CDT committers to install the Zylin Embedded CDT plugin,
or other plugins for that matter, so a reproduction scenario should only
include CDT code. JUnit(or similar) test cases would of course be nice here.



--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

[John Cortell]

At 01:14 PM 3/31/2008, Øyvind Harboe wrote:
> > I very rarely change code based purely on inspection. I like to see
> > something fail before I go fix it, especially if it's something
> > reported by someone else...even if it looks obvious. I'm assuming you
> > found this not by code inspection by actually seeing a nondescript
> > error message surface. If you did, and it can be reproduced with a
> > standard gdb/mi session, telling me what those steps are will make
> > things easier for me. Otherwise, I have to go rig the code to
> > manufacture the scenario I think you're having.
>
>Since CDT is something that plugins can build on,
>I'm sure that this is a familiar problem: you can't exercise
>all your code paths using CDT alone.
>
>As I recall this problem *can* happen with normal CDT, but it
>becomes severe w/e.g. the Zylin Embedded CDT plugin. The Zylin Embedded
>CDT pushes error handling into GDB as much as possible as GDB
>is capable of a lot more than CDT really knows about w.r.t. what file
>formats are supported, whether files are really required for to debug, etc.
>
>I don't expect the CDT committers to install the Zylin Embedded CDT plugin,
>or other plugins for that matter, so a reproduction scenario should only
>include CDT code. JUnit(or similar) test cases would of course be nice here.

And that is fine. I did footnote my original
request with this possibility. I'll take it from here.

John

[Øyvind Harboe]

On Mon, Mar 31, 2008 at 8:24 PM, John Cortell
<john.cortell-***@public.gmane.org> wrote:
>
> At 01:14 PM 3/31/2008, Øyvind Harboe wrote:
> > > I very rarely change code based purely on inspection. I like to see
> > > something fail before I go fix it, especially if it's something
> > > reported by someone else...even if it looks obvious. I'm assuming you
> > > found this not by code inspection by actually seeing a nondescript
> > > error message surface. If you did, and it can be reproduced with a
> > > standard gdb/mi session, telling me what those steps are will make
> > > things easier for me. Otherwise, I have to go rig the code to
> > > manufacture the scenario I think you're having.
> >
> >Since CDT is something that plugins can build on,
> >I'm sure that this is a familiar problem: you can't exercise
> >all your code paths using CDT alone.
> >
> >As I recall this problem *can* happen with normal CDT, but it
> >becomes severe w/e.g. the Zylin Embedded CDT plugin. The Zylin Embedded
> >CDT pushes error handling into GDB as much as possible as GDB
> >is capable of a lot more than CDT really knows about w.r.t. what file
> >formats are supported, whether files are really required for to debug, etc.
> >
> >I don't expect the CDT committers to install the Zylin Embedded CDT plugin,
> >or other plugins for that matter, so a reproduction scenario should only
> >include CDT code. JUnit(or similar) test cases would of course be nice here.
>
> And that is fine. I did footnote my original
> request with this possibility. I'll take it from here.

The thing that worries me the most is that I found one place where this
happens.

Are there more?

Can they be found via a grep/query?




--
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit