exception handling fscanf_s example

Question

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 11-May-12 3:54am

T2102

Updated 11-May-12 21:30pm

Aescleal

v2

Add a Solution

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

enhzflep · Answer 1 · 2012-05-11T04:13:00

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[^])

Aescleal · Answer 2 · 2012-05-11T22:31:00

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

T2102 · Answer 3 · 2012-05-11T04:17:00

Solution 2

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.

Posted 11-May-12 4:17am

T2102

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/

exception handling fscanf_s example

3 solutions

Solution 1

Solution 3

Solution 2

Add your solution here

Preview 0