I’ve read that try catch is considered “bad code” I don’t care much about that, …
I’ve read that try catch is generally slower - does that mean allways, …
I usually like to use if statements, BUT atm I was thinking HOW would I make an if statement that it wouldn’t go through if statement multiple times, and I was thinking OH could try catch be the solution, …
anyway IF
try{
// is not nre
return true;
}
catch{
return false;
}
is not NRE witch 99.999% of the time isn’t
BUT is NRE few times,
would try/catch be faster in this case OR would it be faster if I’d make if statements as I was usually doing them?
ALSO when would you consider doing finally as better way?
and I’ve never used or read how finally works can someone explain it a bit please?
I wonder, where you got the idea, that try … catch is an alternative to if … else.
try … catch is for catching exceptions and nothing else. So if you have code that might throw an exception (e.g. file I/O), you will need to surround it with a try … catch block, or your game will crash. There’s no way to do this with an if … else.
The finally block will be executed, even if there was an exception. This can be used to clean up resources. For example if you’re working with files, you might want to close the file, even when there’s an error.
if-else is designed to control the logical flow of your application. try-catch-finally is not. Could I drive to work in a fan-powered canoe on wheels? Sure - but I’d probably be better off just using my car instead.
public static void Interupt(int Index, string Text){
try{
Change(Transforms[ Index ], Text);
}
catch{
throw new System.InvalidOperationException("Index: " + Index + " Is too large should be less than: " + Transforms.Count);
}
}
than this:
public static void Interupt(int Index, string Text){
if(Transforms.Count<Index){
Change(Transforms[ Index ], Text);
}
else{
throw new System.InvalidOperationException("Index: " + Index + " Is too large should be less than: " + Transforms.Count);
}
}
Throwing an Exception is going to be the most expensive operation in that code. Your if statement prevents the Change() method from being called and also prevents any Exception Change() would throw from being thrown. So the answer isn’t that try-catch is slower or faster it’s that you’re performing different actions with those 2 pieces of code.
Why are you manually throwing exceptions? Those would have to be caught with a try/catch otherwise they are runtime errors that you created and didn’t handle.
Why are you manually throwing an exception inside a catch? If you’re in the catch, you’ve already caught the exception, now you must handle it, not throw a new exception.
@KelsoMRK I ment the output behaviour, … @NA-RA-KU NO I can’t handle it because I must stop the program and write different code and that’s pretty much intentional. It’s because I’m interfering with private members that needs to be private.
re-throwing in a catch block is pretty standard. You can wrap an Exception in your own Exception that maybe explains what happened a little more contextually.
My point was that the try-catch will incur the overhead of the method call and the overhead of throwing whatever Exception Change() throws and therefore it will be slower.
This isn’t even about the behaviour of the Change method.
If Index is negative or too large, an IndexOutRangeException is thrown. And there’s absolutely no good reason to throw a new InvalidOperationException. This is just misleading and gains nothing. Apart from that the exception handler catches all exceptions and claims that the Index was too large. Even if it was negative or some other exception was thrown in Change. Last but not least by throwing a new exception the stacktrace is lost.
To rethrow an exception you would use this constructor:
public InvalidOperationException(
string message,
Exception innerException
)
This is just no way to handle exceptions. And speed has nothing to do with it.