C#•4y ago

Exception vs Logic

Hello, im going to read a file with File.Readlines().

I read that its better to use logic(like a if-statement) rather then try/catch.

Which of these two would you say is better practice?
Option 1.
try{
fileLines = File.ReadAllLines(fileName);
}catch { throw; }

Option 2.
if (File.Exists(fileName))
{
try
{
fileLines = File.ReadLines(fileName);
}
catch { throw; }
}else { throw new FileNotFoundException(); }

Im thinking option 1 will throw filenotfoundexception either way, and therefore its no reason to check it like in option 2?

Thanks in advance!

Angius•8/25/22, 1:42 PM

is one of the most useless lines of code you can write

Angius•8/25/22, 1:43 PM

Catching an exception just to throw serves no purpose

Angius•8/25/22, 1:43 PM

Yes, ideally, you should check if the file exists first, then read the file, and not catch the exception

nax•8/25/22, 1:43 PM

Unless you're providing the file elsewhere via your method, you might as well use the latter. Only catch an error if you're going to handle it (ie, display a message to the end user)

nax•8/25/22, 1:45 PM

the less exceptions all around the better.

Mayor McCheese•8/25/22, 1:49 PM

Also, catching should be as high as possible, so when you catch exceptions be as specific as possible for as long as possible

big OOFOP•8/25/22, 1:50 PM

Okey thanks you for the input, its a console app and i want to tell the user if the file dosent exist. Is this looking better?

if (File.Exists(fileName))
{
try{
ileLines = File.ReadLines(fileName);
}
catch(Exception ex) { Console.WriteLine($"Something went wrong when reading file. Message: {ex.Message}. Stacktrace: {ex.StackTrace}"); }
}
else{ Console.WriteLine("File dosent exist!"); }

Mayor McCheese•8/25/22, 1:51 PM

why do you have the try/catch at all?

big OOFOP•8/25/22, 1:51 PM

My thought is that it might occur an error when reading the file: fileLines = File.ReadLines(fileName);

Mayor McCheese•8/25/22, 1:52 PM

logging isn't handling the error

Mayor McCheese•8/25/22, 1:52 PM

so, if it happens it will bubble up to the caller anyway

big OOFOP•8/25/22, 1:53 PM

Okey! So maybe i just check if the file exist, if so -> Read file?

Mayor McCheese•8/25/22, 1:56 PM

so, catch(Exception ex) is usually bad idea

Mayor McCheese•8/25/22, 1:56 PM

you want that to be as high as possible

Mayor McCheese•8/25/22, 2:04 PM

when you catch Exception like that anything that goes wrong ends up in the catch block

nax•8/25/22, 2:05 PM

For reference (idk if the bot can post here)
put your code in like this

```cs
// code here
```

Monsieur Snowholesome•8/25/22, 2:06 PM

I really like what mlem once said
Using File.Exist beforehand, just to read the file afterwards is really useless
The trillion amount of factors that could cause not being able to read the file exceed the use of File.Exists,

Between the check and the actual reading, the file could be gone - Not really reliable
During reading, the file could vanish, now you couldnt read it and the file is gone, though you checked it beforehand

Bbig OOF Okey thanks you for the input, its a console app and i want to tell the user if ...

nax•8/25/22, 2:07 PM

nax•8/25/22, 2:08 PM

The docs list the exceptions that a method might throw as well as the causes for those exceptions. For example, ReadLines: https://docs.microsoft.com/en-us/dotnet/api/system.io.file.readlines?view=net-6.0

Mayor McCheese•8/25/22, 2:08 PM

catch those exceptions that are known, if you can handle them

nax•8/25/22, 2:09 PM

Or even handle them ahead of time. If the user is inputting a 0 length path for example, tell them that they can't

Mayor McCheese•8/25/22, 2:10 PM

guard statements are good

nax•8/25/22, 2:10 PM

ArgumentNull exceptions are easily mitigated by using nullable contexts but I wouldn't want you to spin too many plates at once if you're still learning.

AAngius Yes, ideally, you should check if the file exists first, then read the file, and...

jcotton42•8/25/22, 2:13 PM

That just leads to a TOCTOU bug later

jcotton42•8/25/22, 2:13 PM

The file could be moved or deleted between the exists check, and the read

jcotton42•8/25/22, 2:13 PM

And just because it exists doesn't mean you have the permissions to read it

jcotton42•8/25/22, 2:15 PM

https://en.m.wikipedia.org/wiki/Time-of-check_to_time-of-use

Time-of-check to time-of-use

In software development, time-of-check to time-of-use (TOCTOU, TOCTTOU or TOC/TOU) is a class of software bugs caused by a race condition involving the checking of the state of a part of a system (such as a security credential) and the use of the results of that check.
TOCTOU race conditions are common in Unix between operations on the file sys...

big OOFOP•8/25/22, 2:17 PM

Okey perfect thank you @Naxane! The only way im going to handle the errors is telling the user(writeline).
Atm my code looks like this:

My thought is:
Check if file exist - otherwise tell user.
Surrond content inside if in try/catch so tell user other errors.
Would you rather suggest me to remove the File.Exists() and catch these specific error in a try/catch?

Bbig OOF Okey perfect thank you @Naxane! The only way im going to handle the errors is te...

jcotton42•8/25/22, 2:18 PM

Yes remove the Exists call
But catch a specific exception type

jcotton42•8/25/22, 2:19 PM

You almost never want to catch Exception itself

big OOFOP•8/25/22, 2:21 PM

Okey ill try that, thanks you! I have a vague memory of taht timCory(the youtuber) said that you want a try/catch at the lowest level - to be able to trace the error via stacktrace. Am i mistaken?

jcotton42•8/25/22, 2:21 PM

You catch exceptions where you can reasonably handle them

big OOFOP•8/25/22, 2:24 PM

Okey, and in this case when its a console app that reads a file. The only ways i can think of handling them is either: 1. Tell user(print message/trace) 2. Throw the caught exception(to make app stop running)

big OOFOP•8/25/22, 2:24 PM

Is there any other way you would handle them?

Mayor McCheese•8/25/22, 2:24 PM

When folks say handle them, they mean deal with the root cause in a graceful way

big OOFOP•8/25/22, 2:25 PM

Ahh okey!

big OOFOP•8/25/22, 2:25 PM

I thought you meant - do something when exception gets caught

Mayor McCheese•8/25/22, 2:26 PM

so lets say that you try to read the file, and it's locked, we could potentially handle that with a retry of some sort right?

nax•8/25/22, 2:26 PM

An input loop that takes the user's query again for example

Mayor McCheese•8/25/22, 2:28 PM

If you don't have permission to the file, a retry won't really help, one is a temporary condition ( the locked file ), the other requires an external action and can't really be easily handled.

nax•8/25/22, 2:28 PM

Alternatively if this is a regular windows environment, open a file dialogue

Mayor McCheese•8/25/22, 2:34 PM

There's also a thing called , the number of things that might go wrong with reading a file is legendary, the more you know about it, the worse it gets; the more edge cases, what-ifs, you get concerned about goes up, but really mostly it's not a problem, things go wrong, plan for things to go wrong, catch the exceptions that your system is designed to handle and protect your application from everything else.

big OOFOP•8/25/22, 2:36 PM

Ive added a division by zero, is this more how the exception handling should be done? (If the zero came from user input maybe restrict the user from not being able to input 0 at the first place) - But just as a example

big OOFOP•8/25/22, 2:38 PM

Forgot the int:

big OOFOP•8/25/22, 2:52 PM

But lets say i catch the error i can handle, for example if i catch the filenotfound exception. If i dont catch the dividedbyzero exception - the program will crash. Im thinking it would be better to catch a general exception(catch(exception ex)) if there are any exception that i have missed?

big OOFOP•8/25/22, 2:52 PM

Or would the better be just to let the program crash? Sorry if im getting it wrong

Monsieur Snowholesome•8/25/22, 3:08 PM

You will want to have a catch all
But for cases where you have certain behaviour on certain exceptions, you add them

Mayor McCheese•8/25/22, 3:19 PM

very naive example

big OOFOP•8/25/22, 3:25 PM

Great example, i really understand this topic more now! It is a bit confusing sometimes