Child Item

Catching path/conflict/folder in CreateFolderV2Async

Not sure if y'all are on StackOverflow (I THINK so?) but I'm having issues with path/conflict/folder exceptions from CreateFolderV2Async, that being that my code successfully catches said exception, but then it still manages to show up in my global unhandled exception handler, which it shouldn't be. Not sure if the issue is with Dropbox or somewhere else, but see https://stackoverflow.com/questions/71634590/c-sharp-handled-exception-from-dropbox-is-coming-up-as-unhandled-exception for full info (reply here and/or there if you're able to shed some light on the issue). Thanks. Donald.

Find more posts tagged with

API

Abuse

Comments

Brogers

Hello @donaldp,

I'm sorry you are running into this issue. From the stack overflow, it seems unclear whether the first or second call is throwing these exceptions that are bubbling up. An easy way to differentiate this would be to just comment out the second line to confirm the first call is properly working.

Based off where the comment you have for folder already existing, it would seem to me that the exception is coming from the first request although it is tough to tell based off the trace provided.

Additionally, can you please note which version of the SDK you are using as well as the specific target for the application (.NET Core, etc)? This should be able to help us further debug the issue.

- Brad

donaldp

Hi Brad @Brogers,

Thanks for your reply.

The message with the result of the call comes up after, so there is no exception before the 1st call, and an exception before the 2nd message (which for some reason is generating 2 exception messages). Some time ago (i.e. back when I was first writing my Dropbox library) the question was raised about how to check if a folder exists, and the response was you just go ahead and try to create it and see if you get an exception, which is what I'm doing. Is that still the case? Cos I'm happy to check if the folder exists first if such a method is now available.

So, my code tries to create the folder, and if I get a path back then I proceed with that code, but if I get the exception back then I proceed with the code for the case of the folder already exists (and thus having dealt with it, I'm not sure why the exception still bubbles up. It's more of an annoyance than anything, but yeah I'd like to solve it if there is a solution - annoying seeing exceptions that you've already dealt with. Makes it harder to find the ones that haven't been dealt with).

Also maybe something to do with FirstChanceException (because from what I've seen UnhandledException only works with console apps, which mine isn't. In any case I couldn't get UnhandledException to work, but then found out about FirstChanceException as a way to catch them. As per this issue here (which I commented on) https://github.com/dotnet/maui/discussions/653 someone said "the FirstChanceException "Occurs when an exception is thrown in managed code, before the runtime searches the call stack for an exception handler in the application domain", so I guess that's saying that FirstChanceException surfaces it before my code handles it?? That's not how I thought it worked, but that's how it sounds like to me with my limited knowledge about it (obviously not a forte of mine).

I'm on .net standard2 at the moment (planning on rewriting my Dropbox library to use .net6 after Visual Studio 2022 becomes generally available), and I'm using dropbox.api 6.13.0 (I did upgrade it recently to 6.25 to see if it fixed another issue I had - which it didn't - and then I downgraded again because otherwise I was going to have to rebuild my existing apps, which again I'd rather wait til I can do my .net6 rewrite before going through all that).

Basically I'm just looking for a way to not have exceptions bubble up if a folder already exists, and open to suggestions of alternative approaches (like if you have an api now for checking if it exists first).

thanks,

Donald

Brogers

It seems like the firstChanceException might be the cause of this, if you remove that, do you get a global uncaught exception or does it just swallow the exception (i.e. is it being thrown there because it is truly globally uncaught, or does the firstChance handler catch it before the exception block does.