Feature request
Feature request
https://quality.embarcadero.com/browse/RSP-18827
it's possible to ignore exceptions in the IDE global settings, but it could be comfortable to set this features by project or much better directly inside the code
{$IGNORE_EXCEPTION ON}
try
test_rights;
except
on e: Exception;
Assert(e.message = 'insuffisant rights');
end;
{$IGNORE_EXCEPTION OFF}
see for instance
https://github.com/tothpaul/Delphi/blob/master/XML/Execute.XML.Tree.pas#L755
https://quality.embarcadero.com/browse/RSP-18827
it's possible to ignore exceptions in the IDE global settings, but it could be comfortable to set this features by project or much better directly inside the code
{$IGNORE_EXCEPTION ON}
try
test_rights;
except
on e: Exception;
Assert(e.message = 'insuffisant rights');
end;
{$IGNORE_EXCEPTION OFF}
see for instance
https://github.com/tothpaul/Delphi/blob/master/XML/Execute.XML.Tree.pas#L755
Well you could trigger a specific exception type (EMyOddException) and ignore only that type, if I remember
ReplyDeleteMarco Cantù yes, but I don't wont to ignore them always, only on the test code where I know that en exception is raised because the test fails if it do not :)
ReplyDeleteGot it. Well, no idea how feasible it is, but I'll open and forward internally....
ReplyDeleteBeen wanting this myself several times.
ReplyDeleteMarco Cantù That requires control over the code raising the exception. For example FireDAC often handles exceptions either gracefully or reraises later, and so the the inner exceptions become debugging noise.
ReplyDeleteIgnoring exceptions is a debugger thing so imo it does not belong as compiler directive into the code.
ReplyDeleteWhat I could think of would be some debugger hooks where you can disable/enable exceptions. That would also be very helpful for unit tests where you have tests that expect some exception and you want to only ignore that particular one.
Stefan Glienke AFAIK the TDS info are build by the compiler, this option should be a TDS tag, so the debugger could know whenever it should ignore or not exception in a portion of code...and the source code is the better place to set this up :)
ReplyDeletePaul TOTH TDS info has nothing to do with the debugger stopping on exceptions - try for yourself, run a release build without any debug information under the debugger and watch the debugger to stop when an exception occurs.
ReplyDeleteStefan Glienke when the debug info are off, it is an acceptable behavior I think.
ReplyDeleteif it is possible to have it on a release version it's better but the main reason why I claim this is to avoid unwanted exception warning at debug time.
do you see any other way to avoid exception warning in a portion of code without putting this information in the source code ?
Paul TOTH Please read more carefully - I wrote not to put it as compiler directive into the code. First because it is not a compiler thing to tell if the debugger should pick up the exception or not (see https://www.microsoftpressstore.com/articles/article.aspx?p=2201303). Second because the decision could be made at runtime which I gave an example for.
ReplyDeleteStefan Glienke I don't understand what bothers you...how do you think a debugger hook could at runtime decides that such exception in such portion of code should be safely ignored ? And of course I don't want to setup this each time I reload the project. I even don't wont to know why another developper as used a silent exception in it's code !
ReplyDelete"how do you think a debugger hook could at runtime decides that such exception in such portion of code should be safely ignored"
ReplyDeleteBy writing something like IgnoreException(EWhatever). And no, this is different from some compiler directive as you suggested.
Read about how Visual Studio provides a way to turn off breaking on exceptions although they have the same mechanics with providing exceptions to ignore in the IDE:
https://stackoverflow.com/questions/1420390/dont-stop-debugger-at-that-exception-when-its-thrown-and-caught
As you can see in the documentation this and the related attributes do not do anything to the generated code but are basically a marker for the debugger to ignore code inside methods marked with that attribute.
While this certainly gives some way to hide exceptions from the debugger to pop up imo its not a very good way and not flexible enough (as its an all or nothing thing - it does not only prevent breaking on exceptions but also putting breakpoints or stepping through).
I would certainly not touch the compiler when implementing this feature but providing something on RTL/debugger level similar to the ReportMemoryLeaksOnShutDown option.
By giving a way to communicate from the debugged process to the debugger via hook/callback you have fine grained and easy access.
FWIW I tried changing the keys in the registry which did not have effect on an already running IDE (as it does not pick up the values from the registry even when opening the options). Now I think somewhere inside the IDE there is some method to refresh these options or set them but afaik there is no publicly available way. I also tried an IOTAThreadNotifier but that one gets notified after the debugger shows its "Debugger Exception Notification" dialog. I think some of the people lurking around in the IDE could figure out something.
Stefan Glienke please, stop thinking on Delphi the way C# is made, each time a new feature from C# is added to Delphi it is made with a lot of bugs and code size explosion.
ReplyDeleteattributes are hidden automatic allocated class attached to the object, it's just horrible.
Come on man ! I just want to avoid a message from the IDE ! not pollute the RTL more.
BTW ReportMemoryLeaksOnShutDown is a runtime feature, nothing to do with a debugger, even if it is a debugging feature.
Paul TOTH You really suffer from selective perception do you? I did not suggest doing it with attributes. It was just to show how they do it and I even commented on the fact that I think it's not a good approach. And I even mentioned that it does not affect the generated code at all.
ReplyDeleteAlso the fact that some people are stupid and try to press things from one language into the other without using their brain (IEnumerable from System.pas comes into mind) does not mean that you cannot look at other languages and check how they do things - in fact almost every time people don't do that (fwiw the R in R&D stands for research) the solution is crap - and I am talking about software development in general.
Also no need to emotionally overreact.
Adding a way to communicate with the debugger to turn off breaking at particular exceptions is hardly polluting the RTL. As I mentioned the only missing piece currently because not publicly available is accessing the debugger options via code. You rather pollute the already groaning and creaking compiler with another option?
Also to correct some misinformation:
"attributes are hidden automatic allocated class attached to the object, it's just horrible."
Attribute objects are only getting instantiated when the attribute class is known at compile time (otherwise you get that custom attributes not supported thing) and read via GetAttributes - before its just some metadata sitting in the binary doing nothing.
Will not read all messages completely, but Stefan Glienke asked the same two years ago plus.google.com - Whoever tells me how I can turn off stopping on exceptions during debugging *... , I have posted a pointer in the thread and of course the following worked https://twitter.com/UScLE/status/637564412635836416 As always a solution is the job of the vendor.
ReplyDelete