Socket Exception if I enable 'break on all exceptions' in VS code

[thomas-watchenterprise]

Is there an existing issue for this?

• I have searched the existing issues
• I have read the guide to filing a bug

Steps to reproduce

In our current app the moment I enable 'break on all exceptions' in VS code and I start the app I get a lot of these exceptions

if I disable this option the app runs without problems

Expected results

no SocketEception

Actual results

Code sample

Code sample

[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration

[Upload media here]

Logs

Logs

[Paste your logs here]

Flutter Doctor output

Doctor output

Microsoft Windows [Version 10.0.19045.2965]
(c) Microsoft Corporation. All rights reserved.

C:\Entwicklung\projects\watchcrunch-mobile-v2>flutter doctor -v
[√] Flutter (Channel stable, 3.10.0, on Microsoft Windows [Version 10.0.19045.2965], locale de-DE)
    • Flutter version 3.10.0 on channel stable at C:\Users\escam\fvm\versions\3.10.0
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 84a1e904f4 (2 weeks ago), 2023-05-09 07:41:44 -0700
    • Engine revision d44b5a94c9
    • Dart version 3.0.0
    • DevTools version 2.23.1

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0-rc1)
    • Android SDK at C:\Users\escam\AppData\Local\Android\sdk
    • Platform android-33, build-tools 34.0.0-rc1
    • Java binary at: C:\Program Files\Android\Android Studio1\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-9505619)   
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.9.3)       
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.9.31129.286
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2022.1)
    • Android Studio at C:\Program Files\Android\Android Studio1
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.15+0-b2043.56-9505619)   

[√] IntelliJ IDEA Community Edition (version 2018.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.2.5
    • Flutter plugin version 29.1.3
    • Dart plugin version 182.4892.25

[√] VS Code, 64-bit edition (version 1.78.2)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.64.0

[√] VS Code (version 1.39.0-insider)
    • VS Code at C:\Users\escam\AppData\Local\Programs\Microsoft VS Code Insiders
    • Flutter extension version 3.4.1

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19045.2965]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 110.0.5481.178
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 113.0.1774.50

[√] Network resources
    • All expected network resources are available.

[darshankawar]

@thomas-watchenterprise
Check this comment and see if it helps in your case.

/cc @DanTup for thoughts if this need to be reported in dart-lang instead ?

[escamoteur]

ah, thanks looks like a fix is in sight #126650 (comment)

[DanTup]

The fix linked above is for the specific exception mentioned in that issue, it won't change any behaviour for this exception.

However, I believe this is working as intended for the same reasons described in #126650 (comment). Checking "all exceptions" is asking to pause on caught exceptions so it will always have some false positives.

You should use "uncaught exceptions" by default, which will not pause on caught exceptions. If there's a reason you feel that doesn't do what you want, please provide an example of where it's not breaking but you think it should because it is very likely better than we improve "uncaught exceptions" than try to eliminate all instances of thrown/caught exceptions in the SDK/packages.

That said, if this error occurs in a common case and adds a lot of noise when you do need to use "all exceptions" there might be an argument for trying to eliminate it as has been done with the linked one. Without a code example of how to trigger this to understand under what conditions it happens, it's hard to say.

[escamoteur]

I mean the given domain is a valid one, so I don't understand at all that it throws any exception.

[DanTup]

@escamoteur are you able to provide a code sample that triggers this? There's not much context in the screenshots so it's hard to tell what's happening.

[escamoteur]

I haven't had the time to create a small repro project but it seems to be related to the linked problem above I guess

[DanTup]

I'm not sure it's related - that issue was specifically about using throw/catch as part of trying to parse an IP address out of a URL (which had a hostname). I could reproduce that, but I could not reproduce this. It's possible it's specific to the hostname you're resolving.

It's difficult to be certain without a way to reproduce this, although as noted above, it is recommended to use "Break on uncaught exceptions" for general debugging. If there's a reason you feel that doesn't do what you need, I'd be very interested to know. "All exceptions" is intended to be used for specific situations and will always have the possibility of "false positives".

[escamoteur]

In my experience there is a certain group of exceptions that give you a stacktrace that isn't helpful at all if you have break on uncaught exceptions. With break on all you break at the position where the exception occurs which isn't the case in the other option

[DanTup]

In my experience there is a certain group of exceptions that give you a stacktrace that isn't helpful at all if you have break on uncaught exceptions.

It's more information about this that I'm interested in. Several people have mentioned there are some cases where this doesn't do what they'd like, but I haven't had any examples yet. If you're able to provide any, that would really help. "All exceptions" will never be the best debugging experience, so we would be better focusing on trying to make "Uncaught exceptions" better. As noted in the other issue, we already have the ability to cause some "technically caught" exceptions to be treated as "uncaught" (for example so Flutter's own error handler doesn't catch everything and prevent breaking), so it might just be that this needs to be applied in more places.

Any examples/repros (for that, or for this original exception) would be really helpful. It's difficult to change these things without steps to reproduce though.

[darshankawar]

@thomas-watchenterprise
Please provide reproducible code sample along with steps to replicate so that we can properly address this issue.

[escamoteur]

@DanTup I'm getting back on this a bit later because I'm too busy at the moment.

[DanTup]

Understood, thanks! I did have another go at trying to reproduce but was not able to.

[github-actions]

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.