Prev: CPropertySheet default border
Next: question about mfc42.dll
From: RaG on 23 Feb 2010 08:01
On Feb 23, 4:32 pm, Ismo Salonen <i...(a)codeit.fi> wrote:
> RaG wrote:
> > On Feb 23, 2:36 pm, "Giovanni Dicanio"
> > <giovanniDOTdica...(a)REMOVEMEgmail.com> wrote:
> >> "RaG" <b.raghaven...(a)gmail.com> ha scritto nel messaggionews:1b201de8-2654-46c8-9bd1-b6f850644880(a)f29g2000yqa.googlegroups.com...
>
> >>> fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n", 0);
> >>> but when I run this on vc9(visual studio 2008)
> >>> an exception is thrown,How to handle the exception is the issue.
> >>> The exception condition will occur definitely but handling that is
> >>> what I need.In vc6 same code is working fine.
> >> What is the exception thrown?
>
> >> The general way of catching exceptions in C++ is by using try/catch, i..e.
>
> >>  try {
> >>    ...
> >>    code
> >>    ...
> >>  }
> >>  catch( const std::exception & e ) {
> >>     std::cerr << "*** ERROR: " << e.what() << std::endl;
> >>  }
>
> >> Giovanni
>
> > exception handling already there, but still the below exception is
> > comming
> > First-chance exception at 0x7c91b21a in unittest.exe: 0xC0000005:
> > Access violation writing location 0x00000010.
>
> My crystall ball tells me that stderr is not open. Is the program a
> console application ? Normal windows applications need to freopen stderr
> themselves.
>
> ismo

My application is multithreaded windows appilcation,In the worker
thread the below statement
if ( (RetCode = DoFormatMessage ( pMFormat, pVariables, pOutString,
MaxStringLength, MaxBufferLength, MessageType )) != SUCCESS )
// tprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
0); is crashing the stderr value is Junk , I think "stderr" defaultly
set,The fprint statement is working fine in sample test application .
From: Joseph M. Newcomer on 23 Feb 2010 11:11
I am very certain that "an" exception is *not* thrown. I am, however, absolutely certain
that there is an exception, whose location is precisely identified, down to the line of
code, and the exception type is named. And, if you enter the debugger, you will see that
source code, you will see the values related to the failure, you can examine the stack
backtrace, and you can analyze what has happened. And it could also be a runtime error,
or an assertion failure. Too many people report "exception" when they mean either of the
preceding actual causes. The message that comes out has text in it. Without that text,
and the stack backtrace, and several lines of the code, there's no way to tell you what
went wrong.

You only show one line here; it is very likely that the line preceding it was the cause of
the error. Lacking the detailed information and the stack backtrace, I can only guess,
but my first guess is that the line preceding it is a FormatMessage, and you probably have
an erroneous parameter. Note that modern compilers are sometimes much less forgiving of
user errors than older compilers. For example, stack overwrites. Modern compilers will
detect errors that VS6 never bothered to look for, and thus your code may have *always*
been incorrect, but it simply wasn't detected before!

The way you "handle" the exception is to fix the error in your program that is causing it.
But since we don't know what the exception is, or where it came from, there's no way to
answer this question.
joe

On Tue, 23 Feb 2010 01:25:21 -0800 (PST), RaG <b.raghavender(a)gmail.com> wrote:

>Hi,
>I converted code from vc6 to vc9, on vc6 environment the below
>statement is working fine
>
>fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n", 0);
>
>but when I run this on vc9(visual studio 2008)
>an exception is thrown,How to handle the exception is the issue.
>The exception condition will occur definitely but handling that is
>what I need.In vc6 same code is working fine.
>
>Any one please Help it is very urgent to solve the exception.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 23 Feb 2010 11:19
See below....
On Tue, 23 Feb 2010 05:01:20 -0800 (PST), RaG <b.raghavender(a)gmail.com> wrote:

>On Feb 23, 4:32�pm, Ismo Salonen <i...(a)codeit.fi> wrote:
>> RaG wrote:
>> > On Feb 23, 2:36 pm, "Giovanni Dicanio"
>> > <giovanniDOTdica...(a)REMOVEMEgmail.com> wrote:
>> >> "RaG" <b.raghaven...(a)gmail.com> ha scritto nel messaggionews:1b201de8-2654-46c8-9bd1-b6f850644880(a)f29g2000yqa.googlegroups.com...
>>
>> >>> fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n", 0);
>> >>> but when I run this on vc9(visual studio 2008)
>> >>> an exception is thrown,How to handle the exception is the issue.
>> >>> The exception condition will occur definitely but handling that is
>> >>> what I need.In vc6 same code is working fine.
>> >> What is the exception thrown?
>>
>> >> The general way of catching exceptions in C++ is by using try/catch, i.e.
>>
>> >> �try {
>> >> � �...
>> >> � �code
>> >> � �...
>> >> �}
>> >> �catch( const std::exception & e ) {
>> >> � � std::cerr << "*** ERROR: " << e.what() << std::endl;
>> >> �}
>>
>> >> Giovanni
>>
>> > exception handling already there, but still the below exception is
>> > comming
>> > First-chance exception at 0x7c91b21a in unittest.exe: 0xC0000005:
>> > Access violation writing location 0x00000010.
>>
>> My crystall ball tells me that stderr is not open. Is the program a
>> console application ? Normal windows applications need to freopen stderr
>> themselves.
>>
>> ismo
>
>My application is multithreaded windows appilcation,
****
STOP RIGHT THERE! WHY ARE YOU DOING AN fprintf TO stderr IN A WINDOWS APP? IT DOESN'T
EXIST!

(Also, what led you to believe that fprintf is thread-safe? It turns out it is, but did
you *really* know that?)

The program was *always* wrong; VS6 probably ignored the statement, but modern compilers
just go ahead and try to use it. Because they know that nobody would be silly enough to
try to write to stderr from a Windows program, so whatever you are asking must be
reasonable, so go ahead and do it anyway.
****
>In the worker
>thread the below statement
>if ( (RetCode = DoFormatMessage ( pMFormat, pVariables, pOutString,
> MaxStringLength, MaxBufferLength, MessageType )) != SUCCESS )
>// tprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
> fprintf (stderr, "Failed FormatMessage - MessageIndex = <%d>.\n",
>0); is crashing the stderr value is Junk , I think "stderr" defaultly
>set,The fprint statement is working fine in sample test application .
****
And it writes the data where? There is no stderr stream in a Windows app, ever! So I
really doubt that it is "working just fine". I suspect it fails silently. I've NEVER
seen it work in a Windows app, because there *is* no stderr stream it can possibly write
to!

The correct code would have been, for a console app,

_ftprintf(stderr, _T("Failed FormatMessage - MessageIndex = <%d>\n");

As already pointed out, it would be pretty obvious if you had entered the debugger; you
would have seen that stderr is NULL. But why would you expect stderr to exist?

I don't believe that stderr=='Junk'. It most likely is NULL, given the exception. This
is what you *should* expect it to be!
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 23 Feb 2010 13:25
Hi Joe,

I suspect you are right in this case, but I've found it useful to protect
file based operations with exception handling code since it doesn't really
slow it down much and some of the SDK functions will throw exceptions in
exceptional conditions. At least if I catch it I can log the reason and my
customer can tell me more about what happened. Sometimes they are access
problems, sometimes things like disk full, etc.

Tom

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:t4v7o5tgabet1aeek2j7fjbnt18v9bieir(a)4ax.com...
> I am very certain that "an" exception is *not* thrown. I am, however,
> absolutely certain
> that there is an exception, whose location is precisely identified, down
> to the line of
> code, and the exception type is named. And, if you enter the debugger,
> you will see that
> source code, you will see the values related to the failure, you can
> examine the stack
> backtrace, and you can analyze what has happened. And it could also be a
> runtime error,
> or an assertion failure. Too many people report "exception" when they
> mean either of the
> preceding actual causes. The message that comes out has text in it.
> Without that text,
> and the stack backtrace, and several lines of the code, there's no way to
> tell you what
> went wrong.


From: Joseph M. Newcomer on 23 Feb 2010 14:02
CFile operations need to be protected with a try/catch block because they really ARE
defined to throw C++ exceptions, specifically, CFileException.

As you point out, when there are cases where it really can throw an exception, that is, a
low-level hardware exception such as 0xC0000005, you need to protect the call with a
_try/_catch block, which is awkard because it plays so poorly with C++.
joe

On Tue, 23 Feb 2010 10:25:06 -0800, "Tom Serface" <tom(a)camaswood.com> wrote:

>Hi Joe,
>
>I suspect you are right in this case, but I've found it useful to protect
>file based operations with exception handling code since it doesn't really
>slow it down much and some of the SDK functions will throw exceptions in
>exceptional conditions. At least if I catch it I can log the reason and my
>customer can tell me more about what happened. Sometimes they are access
>problems, sometimes things like disk full, etc.
>
>Tom
>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>news:t4v7o5tgabet1aeek2j7fjbnt18v9bieir(a)4ax.com...
>> I am very certain that "an" exception is *not* thrown. I am, however,
>> absolutely certain
>> that there is an exception, whose location is precisely identified, down
>> to the line of
>> code, and the exception type is named. And, if you enter the debugger,
>> you will see that
>> source code, you will see the values related to the failure, you can
>> examine the stack
>> backtrace, and you can analyze what has happened. And it could also be a
>> runtime error,
>> or an assertion failure. Too many people report "exception" when they
>> mean either of the
>> preceding actual causes. The message that comes out has text in it.
>> Without that text,
>> and the stack backtrace, and several lines of the code, there's no way to
>> tell you what
>> went wrong.
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CPropertySheet default border
Next: question about mfc42.dll