1

Is is possible to know if a certain exception can be thrown inside a code block?

The premise: Assume you are working on some old codebase and you have something like this.

try{
  a lot of code that calls a bunch of other methods
}
catch (CustomException e){
  some handling
}

I want to know what code in the try block that can throw this exception. For all I know nothing is throwing it anymore and this is just dead code. I know this is caused by bad code design, but when working with real code it is not always possible to prioritize refactoring all of the old code.

So in short, is it possible to tell at compile time if anything in the try block actually throws that exception?

(if it matters I am coding in idea rider)

Edit: stackoverflow thinks this question already has an aswer to this question, but in reality that question does not have a good answer to anything.Question

Chippen
  • 349
  • 2
  • 9
  • Technically, a code analysis for this is possible, but there are no easy-to-use tools for this I would be aware of. You could check where `CustomException` is thrown and look for all possible call paths, but that's difficult to do (unless there are only few places) – PMF Apr 16 '21 at 05:55
  • Indeed that would be an awesome piece of refactoring tool. But I second PMF: Not aware of anything that does it out of the box. – Fildor Apr 16 '21 at 05:57
  • Thank you, in my current case the CustomException is littered throughout the codebase so following the call path is close to insanity. – Chippen Apr 16 '21 at 06:03
  • 1
    I don't think the question marked as duplicate is a duplicate for this problem. This is about refactoring (because one _thinks_ an exception might never actually happen), not about runtime behavior. – PMF Apr 16 '21 at 06:05
  • 1
    @PMF: of course it's a duplicate. The exact scenario is irrelevant; what matters is whether there's a reliable way to tell whether any exception or even a specific exception can be thrown, and the answer to all those questions is the same: there's not. This is a duplicate of https://stackoverflow.com/questions/9745703/how-to-tell-whitch-exceptions-a-net-call-throws, https://stackoverflow.com/questions/44556805/how-to-check-if-a-function-throws-an-exception-in-c, https://stackoverflow.com/questions/18316535/how-to-know-if-some-method-can-throw-an-exception, and ... – Peter Duniho Apr 16 '21 at 06:10
  • ... https://stackoverflow.com/questions/4263871/how-can-i-know-what-kind-of-exception-a-class-will-throw – Peter Duniho Apr 16 '21 at 06:10
  • @PeterDuniho While it _may_ be duplicate to one or more of your examples, it wasn't to the one that it was marked a duplicate of at the time the comment was written. – Fildor Apr 16 '21 at 06:13
  • @Fildor: I disagree. This is clearly a duplicate of all four. They all ask essentially the same question, and all have essentially the same answer. There is nothing new in this question, and it shows a complete lack of effort to research to boot. – Peter Duniho Apr 16 '21 at 06:14
  • @PeterDuniho Then I agree that we disagree, at least partly. – Fildor Apr 16 '21 at 06:14
  • 1
    There answer is no.... the duplicates answer this. Also, instead of worrying about the semantics of what is a good duplicate, there are more important things to consider. like what is for dinner tonight – TheGeneral Apr 16 '21 at 06:15
  • 1
    @Fildor: the original close target asks _"How can I know which exceptions a method can throw?"_, and the answer replies _"there is no inherent way of knowing what exceptions a method will throw"_, which is exactly the question asked here and the answer to that question. Even the original author of this question has essentially copy/pasted that exact answer to their own question, below. – Peter Duniho Apr 16 '21 at 06:16
  • I will accept that it is a duplicate. Although the answer no to a 3 year old question is not really helpful. And even if that is the correct answer, it is still possible that someone would know of a good technique to work around the specific scenario. – Chippen Apr 16 '21 at 06:24
  • _"the answer no to a 3 year old question is not really helpful"_ -- really? I guess we should just delete all the questions and answers older than three years then? No. The fact is, the age of the answer is irrelevant. And asking the same question again three years later is not useful, especially when it's clear you didn't review the existing answers. And it's not just _one_ three-year-old answer; there are at least _four_ duplicates to this question on the site. It's great if you have some new angle you want to ask about, but that's not the case here. – Peter Duniho Apr 16 '21 at 06:28
  • @Chippen: I'll give the General and Peter that the question _as formulated in the title is answered in the suggested dupes_. Some more, some less helpful for the questions posed there. What I disagree with is that your question is actually the same question. And none of the supposed dupes is in any way helpful to _you_ outside the fact of the answer being "no, cannot do that at compile time, you need to look into the docs and/or decompiler". But maybe I am nitpicky. – Fildor Apr 16 '21 at 06:28
  • @Fildor: if the question is "can I jump from here to the moon with my own two feet?", answering "no" is simply the best anyone can do. There's not any answer to this question other than the same "no" seen in all the duplicates. How can you claim those aren't helpful? They are literally as helpful as can possibly be. There's no other answer to this question. – Peter Duniho Apr 16 '21 at 06:29
  • @PeterDuniho I obviously lack the ability to make clear to you, what and and where I see that this question is different from the others and why they are helpful in their own right but not for OP **outside the common denominator "no, cannot do that"**. And the argument about it isn't helpful for anyone, neither. – Fildor Apr 16 '21 at 06:32
  • @PeterDuniho At least two of the supposed dupes _do_ give more than "no". They suggest workarounds. Only not aimed at the problem OP has but at the problem the OPs of those questions had. My anser to Chippen (on top of "no") would be some kind of static code analysis tool, which I know none that already does exactly this. So not really an answer. And that's my last word on this. I am wasting both of our time. – Fildor Apr 16 '21 at 06:38
  • @Fildor: _"My anser to Chippen (on top of "no") would be some kind of static code analysis tool"_ -- if that were an answer to this question, then this question would be off-topic, as any question asking for recommendations for third-party tools, libraries, etc. would be. – Peter Duniho Apr 16 '21 at 06:39
  • @PeterDuniho Oh my gosh, Peter. How would OP know _that_ beforehand? I am out for today. Need to grab a coffee, now. – Fildor Apr 16 '21 at 06:41
  • @Fildor: _"How would OP know that beforehand?"_ -- how would they know that someone would come along and misinterpret their question as a request for a recommendation for a third-party tool? Well, I guess they couldn't. Not sure how that's relevant though. That particular point is with respect to the wrong answer to the question, not the question itself. I'm just pointing out the logical fallacy in you relying on your misinterpretation of the question as justification for saying it's different from the others. – Peter Duniho Apr 16 '21 at 06:43
  • 1
    I am really sorry this got into a big fight. This is why I hate asking on stack overflow. It is always assumed that the OP only wants an explanation of what the doc means not to have a discussion about a general problem statement. I will just log the exception in a clear way and then run the code in prod over a time period and see if it shows up and then make take a real world decision if it is worth keeping. – Chippen Apr 16 '21 at 06:47

1 Answers1

-1
  • No there is no automatic technique
  • Yes there is a manual techniques: You look at the definition of the reference: for .net component you see in comment the input args, return and exceptions susceptible to trigger, but this is manual approach that must be done on all targeted methods.

If your target code has undefined behavior, I suggest that you enhance your exception handling on time, and start with most generic exception in your first version. You log the content of exception analyse what is it then add this new type of exception in your error handling. in all the case if you let general exception in the end of catch you will catch everything and this is a current practice.

While your answer describes a method to handle the situation, it is not really an answer to the question. – Fildor

Yes it is an answer, do you know an automatic technique to list all Exceptions that can be triggered on a target code ?

But in existing code it might be pretty dangerous to remove a catch block that handles a specific exception in a specific way. – Chippen

Where do I suggest tor Remove a catch block ? If your target code already catches an exception, your caller code is not impacted by it as it will not see any exception, and there is no use to do this.

If however you see explicitly in the target code that an exception is triggered with static code analysis, and if you want to see how to trigger it, you can design a unit test and create a scenario with special input to specifically trigger the code path, and to expect the exception in the test definition.

In fact there is a problem of understanding between your question and my answer. You want to ask.: For a given exception type, is there a way to know that a given target code can throw this exception. Answer is you must analyse it manually or try to fuzz. My initial answer target another question which would be: for a given target code is it possible to know all exceptions that could be triggered.

Thierry Brémard
  • 625
  • 1
  • 5
  • 14
  • While your answer describes a method to handle _the situation_, it is not really an answer to _the question_. – Fildor Apr 16 '21 at 06:00
  • I don't think this is a good idea. The OP already has a very specific exception in place and he wants to know if _that_ exception can ever happen. Adding more general exceptions doesn't help there. – PMF Apr 16 '21 at 06:01
  • 1
    Yes for new code that is a good rule of thumb. But in existing code it might be pretty dangerous to remove a catch block that handles a specific exception in a specific way. – Chippen Apr 16 '21 at 06:02