Click here to Skip to main content
15,920,664 members
Please Sign up or sign in to vote.
4.00/5 (2 votes)
See more:
In Visual Studio 2010 project properties, I have Enabled C++ exceptions with SEH Exceptions.

I intentionally omit the buffer size in a call to fscanf_s to test my exception handling, which fails to catch the error.

I used catch(...) and also utilized an article at
//http://thunderguy.com/semicolon/2002/08/15/visual-c-exception-handling/3/


Is there a better reference? I want to prevent crashes and would rather exit gracefully.

C#
FILE *File_Pointer=0;
            fopen_s(&File_Pointer, CSV_File.c_str(), "r");
        if (!File_Pointer)
            ;
        else {
            //the first line should be Calc_Status
            //why is this not catching the access violation?
            //is it the fscanf_s that prevents this??
            win32_exception::install_handler();
            try {
                long const BUFFER_SIZE=512;
                while (!feof(File_Pointer)) {
                    char buffer[BUFFER_SIZE];
                    fscanf_s(File_Pointer, "%s", buffer); //uncaught access violation or stack overflow without the size
                }
            }
            catch (const access_violation &c) {
                c;
            }
            catch (const win32_exception &c) {
                c;
            }
            catch(...) {
                ;
            }
            fclose(File_Pointer);
Posted
Updated 11-May-12 21:30pm
v2

fscanf & fscanf_s are both part of the C runtime library, and as such, they don't raise an exception on failure.

To raise an exception, you need to either
(a) wrap these functions in c++ code, throwning the exceptions yourself when an error is detected.
(b) just use c++ file-handling routines. i.e fstream (fstream help cpluspls.com[^])
 
Share this answer
 
v2
Aside from the sheer comedy of not using RAII in a program to test exception handling, why do you expect a crash in the call to fscanf_s? Access violations only happen when you access pages of memory that hasn't been committed to a process and as your process "owns" everything you're writing to it won't crash.

When one of the scanf family overwrites the buffer it'll damage/destroy the stack for the function it's called in and those that called it. So the crash will only occur at the earliest when something like these examples happen:

- you dereference a now invalid pointer or reference
- try and return into the middle of somewhere there are no code pages mapped
- you raise an exception that tries to access a trashed exception record [1]
- return somewhere in your process's code you shouldn't and either
-- try and execute an illegal instruction (say you've returned into the middle of it)
-- as the stack won't be a valid one for your function you do any of the things above

As your code doesn't do any of these things until after the try block has completed there's not a lot of chance of the exception being raised until after the code that's been written to handle it has been and gone.

If you want to test whether win32 structured exceptions are happening and being caught don't arse about with functions from the standard library - do something really brutal and direct:
C++
int *p = 0; *p = 0;

That'll show up really quickly whether your exception filter is working or not.

Cheers,

Ash

[1] for compilers that use code based exceptions

Edit for effing useless indent feature
 
Share this answer
 
v3
Comments
T2102 13-May-12 20:11pm    
The call to fscanf_s without a buffer size does cause exceptions with Visual Studio 2010. That's the point of using it as an example.
enhzflep 13-May-12 22:32pm    
Could you post an example of code that fails?
When you say "without a buffer size", do you mean with that parameter missing from the function call, or do you mean with a size that's zero?
Surely, if the parameter was missing you'd simply get a compiler error?
Aescleal 14-May-12 2:46am    
It's a variable length argument list - the compiler can't check the parameters.
enhzflep 14-May-12 2:50am    
Oh yes, of course. I see now.
Bugger! That'll learn for for disregarding the age-old adage: RTFM!
Thanks.
Aescleal 14-May-12 2:28am    
It might cause any sort of program error, but not where you reckon it does. It messes up the stack so the exception will happen when something happens to:

- an automatic variable that's now in a screwed up state
- a return to an address that's not marked as a code page

I've bunged random scanf family function calls in 6 different programs and they all crashed, but none crashed at the site of the sprintf style call. Why not trace your code through with a debugger and see where it all goes wrong?

And if you want a function to screw your code up to cause an exception write code to actually cause the exception you want WHEN you want it and don't fanny about with something that'll fail some indeterminate time in the future.
I understand that I do not need to use fscanf. The issue is that I am trying to prevent uncaught run-time exceptions in general since they are completely unacceptable in my application. I should only return an error code and not cause a whole application to crash.
 
Share this answer
 
Comments
enhzflep 11-May-12 11:13am    
Sure, you won't have any if you continue to use the (unwrapped) C runtime library - because...... C does NOT use the exception mechanism - it utilizes error-codes. But you will have unhandled errors - semantics, sure.

At least fscanf(_s) is easy to use - you know how many variables you are using it to interpret, you also get the return value, telling you how many items were successfully converted.

Though here's the C++ equivalent(complete with exceptions thrown) for fscanf & some pros

http://stackoverflow.com/questions/2334735/c-what-benefits-do-string-streams-offer
http://www.cplusplus.com/reference/iostream/stringstream/

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900