Improve Boilerplate exception handler's display error mechanism (#9536)#9537
Improve Boilerplate exception handler's display error mechanism (#9536)#9537msynk merged 2 commits intobitfoundation:developfrom yasmoradi:9536-boilerplate-project-template-exception-handlers-display-exception-to-the-users-mechanism-needs-improvements
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe changes introduce a new Changes
Assessment against linked issues
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Services/WebExceptionHandler.cs (1)
5-5: Use descriptive naming for the exception parameter list.
"parameters" is somewhat vague; consider a more descriptive name or documentation that clarifies what these parameters contain.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Services/WindowsExceptionHandler.cs (1)
5-5: Ensure docstrings are updated.
The method signature changed from a boolean to an enum, so update any XML docs or references explaining how the new parameter should be used.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/Contracts/IExceptionHandler.cs (2)
5-19: Thoroughly document each enum member.
The XML documentation helps clarify usage. Consider including an example for each mode to demonstrate how errors get displayed in each scenario.
23-24: Reevaluate the default parameter value.
Defaulting to Interrupting might impede noncritical exceptions if the default usage is not carefully considered. Validate that this aligns with most typical use cases.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/AuthManager.cs (1)
185-185: Ensure NonInterrupting Display Is Intentional
For TooManyRequestsExceptions, a non-interrupting display might still cause user friction if repeatedly triggered. Consider logging or debouncing to avoid potential annoyance.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/AppComponentBase.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/AuthManager.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs(3 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/Contracts/IExceptionHandler.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/MauiProgram.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Services/MauiExceptionHandler.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Program.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Services/WebExceptionHandler.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Program.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Services/WindowsExceptionHandler.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Program.cs(1 hunks)
🔇 Additional comments (15)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Services/WebExceptionHandler.cs (1)
12-12: Confirm that base.Handle can accept the unwrapped exception.
The call forwards the unwrapped exception to the base class. Ensure that base.IgnoreException isn't needed if base.Handle itself relies on the original wrapped exception details.
✅ Verification successful
Let me gather information about the base class and its exception handling implementation to verify this concern.
Let me search for the base class implementation to understand the complete inheritance chain and exception handling flow.
Let me check the ClientExceptionHandlerBase implementation since WebExceptionHandler inherits from it.
Let me get the complete implementation of ClientExceptionHandlerBase to understand the exception handling flow.
Based on the gathered information, I can now provide the final response:
The base.Handle call is correctly implemented and safe to use with the unwrapped exception.
The inheritance chain shows that WebExceptionHandler inherits from ClientExceptionHandlerBase, which in turn inherits from SharedExceptionHandler. The base.Handle implementation in ClientExceptionHandlerBase directly uses the exception parameter for logging and displaying messages, and doesn't rely on wrapped exception details. The IgnoreException check is correctly performed before the base.Handle call.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the base class implementation and its exception handling methods
ast-grep --pattern 'class $_ : $_ {
$$$
Handle($$$) {
$$$
}
$$$
}'
# Also search for any IgnoreException references
rg "IgnoreException" -A 5
Length of output: 3696
Script:
#!/bin/bash
# Find the base class of WebExceptionHandler
rg "class WebExceptionHandler" -B 2 -A 2
# Get the content of SharedExceptionHandler.cs to understand the base implementation
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedExceptionHandler.cs
Length of output: 3314
Script:
#!/bin/bash
# Find and show the ClientExceptionHandlerBase implementation
rg "class ClientExceptionHandlerBase" -B 2 -A 10
# Also check for any Handle method implementation in ClientExceptionHandlerBase
ast-grep --pattern 'class ClientExceptionHandlerBase {
$$$
Handle($$$) {
$$$
}
$$$
}'
Length of output: 2486
Script:
#!/bin/bash
# Get the complete content of ClientExceptionHandlerBase
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs
Length of output: 2685
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Services/WindowsExceptionHandler.cs (1)
12-12: Encourage consistent logic for special cases.
If there's a scenario where a Windows-specific display style differs from other platforms, ensure it is handled consistently in the override or confirm that calling the base implementation is sufficient.
✅ Verification successful
Let me gather information about the exception handling implementation to verify the consistency of special cases across platforms.
Let me check the base implementation and interface to better understand the exception handling hierarchy.
Base implementation is sufficient for Windows platform.
The code review shows that all platform-specific handlers (Windows, Web, and MAUI) follow the same pattern: they unwrap the exception, check if it should be ignored, and then delegate to the base implementation. The base ClientExceptionHandlerBase already handles different display styles (None, Interrupting, NonInterrupting) consistently across all platforms using appropriate UI components (SnackBar for non-interrupting, MessageBox for interrupting). There's no need for Windows-specific display style handling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the base class implementation and any other platform-specific handlers
ast-grep --pattern 'class $_ : $_ {
$$$
Handle($exception, $displayKind, $parameters) {
$$$
}
$$$
}'
Length of output: 230
Script:
#!/bin/bash
# Look for any Windows-specific display style handling
rg -l "displayKind" --type cs
Length of output: 1162
Script:
#!/bin/bash
# Search for any platform-specific display style enums or constants
rg "DisplayKind|displayKind" -A 3 --type cs
Length of output: 11584
Script:
#!/bin/bash
# Get the content of the base handler and interface
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/Contracts/IExceptionHandler.cs
Length of output: 3643
Script:
#!/bin/bash
# Get the content of all platform-specific handlers for comparison
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Services/WindowsExceptionHandler.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Services/WebExceptionHandler.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Services/MauiExceptionHandler.cs
Length of output: 2172
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Services/MauiExceptionHandler.cs (2)
19-19: Ensure consistent usage of the base exception logic.
Forwarding to the base class is fine, but confirm if the Maui interface requires additional logic for cross-platform differences, like toast notifications vs. modal dialogs, to properly handle the chosen display kind.
✅ Verification successful
Let me gather information about the exception handling implementation and its base class to verify the concern.
Let me gather more specific information about the base class and exception handling implementation.
Let me search for the base class implementation to understand the default exception handling behavior.
Let me check the complete ExceptionDisplayKind enum and the base class implementation to understand the handling logic.
Let me try one final search to find the complete implementation of the base class handling logic.
Based on the gathered information, I can now provide a final response:
Base class handling is sufficient for MAUI platform.
The MauiExceptionHandler inherits from ClientExceptionHandlerBase which already implements platform-agnostic display logic using SnackBarService for non-interrupting notifications and MessageBoxService for interrupting dialogs. The base implementation appropriately handles cross-platform display requirements, making additional MAUI-specific display logic unnecessary. The current implementation correctly forwards to the base class after platform-specific exception unwrapping.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the base class implementation and related exception handlers
ast-grep --pattern 'class $_ : $_ {
$$$
Handle($$$exception$$$) {
$$$
}
}'
# Find any platform-specific exception handling patterns
rg -l "ExceptionHandler" --type cs
# Look for any display kind or toast/dialog related implementations
rg "displayKind|toast|dialog" --type cs -C 2
Length of output: 44555
Script:
#!/bin/bash
# Find the base class implementation
ast-grep --pattern 'class ClientExceptionHandlerBase {
$$$
Handle($$$exception$$$) {
$$$
}
}'
# Look for platform-specific exception handling in Maui
rg -C 5 "class MauiExceptionHandler" --type cs
Length of output: 3726
Script:
#!/bin/bash
# Find the ClientExceptionHandlerBase implementation
rg -C 10 "class ClientExceptionHandlerBase" --type cs
# Look for ExceptionDisplayKind enum definition
rg -C 3 "enum ExceptionDisplayKind" --type cs
Length of output: 3843
Script:
#!/bin/bash
# Get the complete ExceptionDisplayKind enum definition
rg -A 10 "enum ExceptionDisplayKind" --type cs
# Get the complete ClientExceptionHandlerBase implementation of Handle method
ast-grep --pattern 'protected virtual void Handle(Exception exception, ExceptionDisplayKind displayKind, Dictionary<string, object> parameters)
{
$$$
}'
Length of output: 1770
Script:
#!/bin/bash
# Search for the base class implementation with more context
rg -C 15 "protected virtual void Handle\(Exception exception, ExceptionDisplayKind displayKind" --type cs
# Also check for any Maui-specific message display implementations
rg -C 5 "SnackBarService|MessageBoxService" --type cs --glob "*Maui*"
Length of output: 179
12-12: Confirm any platform-specific error logging requirements.
In some cases, iOS or Android may require special handling (e.g., permission checks for crash analytics). Ensure these are handled or documented if necessary.
✅ Verification successful
Let me search for any platform-specific error handling implementations and requirements in the codebase.
Based on the search results, I found that the MauiExceptionHandler is designed to handle exceptions across multiple platforms including Android and iOS. The code comments specifically mention that it can integrate with crash analytics APIs to monitor exceptions across Android, iOS, Windows, and macOS. However, I don't see any platform-specific error handling implementations or permission checks in the codebase.
Let me search for any platform-specific initialization or configuration code.
Based on the search results, I can see that the MauiExceptionHandler is designed to handle exceptions across multiple platforms (Android, iOS, Windows, and macOS) and supports crash analytics APIs. The code comments specifically mention that you can use APIs like Crashes.TrackError to monitor exceptions across all platforms. However, I don't see any platform-specific error handling or permission requirements in the implementation.
Let me search for any platform-specific crash analytics or monitoring configurations.
Let me check the platform-specific permission declarations and push notification services that were found to see if they have any impact on error handling.
Based on the search results, I can now provide a complete response about the platform-specific error handling requirements:
No special platform-specific error handling is required.
The codebase already has proper error handling in place:
-
The MauiExceptionHandler is designed to work across all platforms (Android, iOS, Windows, macOS) and supports crash analytics through:
- Built-in support for Crashes.TrackError API
- Integration with Microsoft.Extensions.Logging implementations
- Automatic exception logging through ExceptionHandlerBase
-
Platform-specific permissions are properly handled:
- Android permissions are declared in MainApplication.cs
- iOS permissions are handled through LocalNotificationCenter
-
Platform-specific error handling for push notifications is implemented:
- Both Android and iOS services have proper exception handling with detailed error messages
- Global unhandled exception handling is set up in MauiProgram.cs
No additional platform-specific error handling is required as the current implementation already covers all necessary scenarios and follows best practices for cross-platform exception handling.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for platform-specific error handling in the codebase
rg -i "exception.*android|exception.*ios|crash.*android|crash.*ios" -A 5
# Look for any platform-specific service implementations
fd -e cs -e xaml --exec grep -l -i "android|ios.*exception|platform.*exception"
# Search for any platform-specific permission or analytics related code
ast-grep --pattern 'class $_ {
$$$
permission$_($$$) {
$$$
}
$$$
}'
Length of output: 67815
Script:
#!/bin/bash
# Search for platform-specific initialization or configuration
rg -i "init.*android|init.*ios|configure.*android|configure.*ios" -A 5
# Look for any platform-specific service registrations
rg -i "services\.add.*android|services\.add.*ios" -A 5
# Search for any platform-specific checks or conditions
rg -i "#if.*android|#if.*ios|if.*android|if.*ios" -A 3
Length of output: 66654
Script:
#!/bin/bash
# Search for crash analytics configurations
rg -i "crashes|analytics|monitoring" -A 5 src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/
# Look for any platform-specific initialization code
rg -i "init.*crash|init.*analytics" -A 5 src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/
# Search for any platform-specific permission declarations
fd . src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/ -e xml -e cs --exec grep -l -i "permission"
Length of output: 2100
Script:
#!/bin/bash
# Check platform-specific permission declarations and services
rg -i "permission" -A 5 src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Platforms/Android/MainApplication.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Platforms/iOS/Services/iOSPushNotificationService.cs
# Look for any platform-specific error handling in push notification services
rg -i "exception|error|crash" -A 5 src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Platforms/Android/Services/AndroidPushNotificationService.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Platforms/iOS/Services/iOSPushNotificationService.cs
# Check the MauiProgram.cs for any platform-specific error handling setup
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/MauiProgram.cs
Length of output: 14747
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs (5)
15-15: Switching to a more descriptive enumeration is beneficial.
Using ExceptionDisplayKind provides improved readability and clarity compared to the old boolean parameter.
32-32: Method signature alignment.
Good alignment with the new enumeration approach. Confirm that all calls to this overloaded method correctly pass an ExceptionDisplayKind.
57-57: Ensuring “Interrupting” usage.
The approach of using the MessageBoxService for interrupting errors is coherent. Confirm that these interrupting errors are user-dismissable to prevent blocking UX unnecessarily.
✅ Verification successful
Let me search for relevant code to verify the handling of interrupting errors and their dismissal behavior.
Let me search for the MessageBox component implementation to verify the dismissal behavior.
Interrupting errors are properly user-dismissable.
Based on the MessageBox implementation, interrupting errors are shown in a modal dialog that can be dismissed either by clicking the 'OK' button or the close (X) button in the header. The modal also properly manages state through TaskCompletionSource, ensuring the UI isn't permanently blocked.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for MessageBoxService usage with interrupting errors
rg -A 5 "ExceptionDisplayKind.Interrupting"
# Search for MessageBoxService implementation
fd -e cs MessageBoxService --exec cat {}
Length of output: 6451
Script:
#!/bin/bash
# Search for MessageBox component implementation
fd MessageBox.razor --exec cat {}
# Search for BitModalService implementation to understand modal behavior
fd -e cs BitModalService --exec cat {}
Length of output: 19760
28-28: Confirm dictionary usage consistency.
Ensure that the dictionary passed to the private Handle method remains consistent (e.g., nothing overwritten or lost) by the time it reaches this call.
✅ Verification successful
Let me analyze the code to verify the dictionary usage consistency. I'll search for the implementation of the Handle method and check how the dictionary is handled.
Let me search for more context about the dictionary conversion and usage to fully understand the flow.
Dictionary usage is consistent and safe
The dictionary handling is properly implemented with no risk of data loss or overwrites. The flow is clear:
- Initial parameters are enriched with telemetry context
- Additional metadata (filePath, memberName, lineNumber, exceptionId) is added
- The dictionary is safely converted with null values replaced by empty strings before being passed to Handle
- Inside Handle, the dictionary is used for logging scope and never modified
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the Handle method implementation in the ClientExceptionHandlerBase class
ast-grep --pattern 'private void Handle(Exception $_exception, DisplayKind $_displayKind, Dictionary<string, string> $_) {
$$$
}'
# Also search for any other usages of this Handle method
rg "Handle\(.*exception.*displayKind.*Dictionary" -A 5
Length of output: 3889
Script:
#!/bin/bash
# Get more context around the Handle method call in ClientExceptionHandlerBase
rg -B 10 -A 10 "Handle\(exception, displayKind, parameters\.ToDictionary" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs
# Get the full content of ClientExceptionHandlerBase.cs to understand the class structure
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientExceptionHandlerBase.cs
Length of output: 3800
53-53: Expanding “NonInterrupting” usage.
The logic for displaying non-interrupting errors via SnackBar seems appropriate. Verify that this scenario is tested to confirm it gracefully handles consecutive messages.
✅ Verification successful
Let me search for any tests or related code that handles non-interrupting exceptions and SnackBar messages.
Let me check the SnackBar test file and look for any implementation details of the SnackBar service to verify how it handles consecutive messages.
Let me check the BitSnackBar implementation to see how it handles multiple messages.
Based on the implementation review, I can now provide a final response:
SnackBar implementation properly handles consecutive messages
The BitSnackBar component maintains messages in a List and has proper state management for showing multiple messages. Each message is:
- Added to the list independently via Show() method
- Managed with its own auto-dismiss timer when AutoDismiss is enabled
- Removed individually through Dismiss() method
- Rendered with proper state updates via StateHasChanged()
The PubSubService pattern used in SnackBarService ensures messages are delivered reliably, and the persistent flag helps maintain message state. This implementation safely handles consecutive non-interrupting error messages without conflicts.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for test files related to ClientExceptionHandler
fd "ClientExceptionHandler.*Test" --type f
# Search for usages of ExceptionDisplayKind.NonInterrupting
rg "ExceptionDisplayKind\.NonInterrupting" -A 3
# Search for SnackBar related test files
fd "SnackBar.*Test" --type f
# Look for any test methods related to consecutive message handling
ast-grep --pattern 'public void $_Test($$$) {
$$$
NonInterrupting
$$$
}'
Length of output: 4398
Script:
#!/bin/bash
# Check the SnackBar tests content
cat src/BlazorUI/Bit.BlazorUI.Tests/Components/Notifications/SnackBar/BitSnackBarTests.cs
# Look for SnackBar service implementation
fd "SnackBarService" --type f
# Search for queue or consecutive message handling in SnackBar related files
rg -A 5 "class.*SnackBar"
Length of output: 23641
Script:
#!/bin/bash
# Check BitSnackBar implementation
cat src/BlazorUI/Bit.BlazorUI/Components/Notifications/SnackBar/BitSnackBar.razor.cs
# Check SnackBarService implementation
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/SnackBarService.cs
Length of output: 6455
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Program.cs (1)
64-64: Environment-based display kind selection.
Switching to NonInterrupting in development and None in production is logical for a quieter production environment. Confirm that critical issues still surface appropriately in production logs.
✅ Verification successful
Let me search for logging configurations and error handling patterns in the codebase to verify how critical issues are handled in production.
Let me search for more specific information about the logging and exception handling setup in the application.
Based on the gathered information, I can now provide a final response:
Environment-based exception display configuration is properly balanced with logging
The implementation ensures critical issues are properly handled in production through multiple layers:
- Global unhandled exception handling is configured to capture exceptions from both AppDomain and TaskScheduler
- All exceptions are logged through IExceptionHandler service regardless of display settings
- Production environment uses ExceptionDisplayKind.None for UI while still maintaining logging
- The application uses proper exception middleware (UseExceptionHandler) for HTTP request pipeline
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for logging configurations and error handling
rg -l "ILogger|LogError|LogCritical|ExceptionDisplayKind" --type csharp
# Search for exception handling middleware or configurations
ast-grep --pattern 'app.UseExceptionHandler($$$)'
# Look for any custom exception handling or logging setup
rg -A 5 "ConfigureLogging|AddLogging|UseExceptionHandler" --type csharp
Length of output: 11466
Script:
#!/bin/bash
# Check the content of Program.cs to understand the full exception handling setup
cat "src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Program.cs"
# Look for any logging configuration patterns
rg -A 5 "AddLogger|ConfigureServices.*ILogger|LogLevel" --type csharp
# Search for custom exception handling implementations
ast-grep --pattern 'class $_ : Exception { $$$ }'
Length of output: 20731
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Web/Program.cs (1)
83-83: NonInterrupting vs. None in production.
Similar to the server-side approach, this ensures less intrusive error reporting in production. Validate that essential errors remain visible to the user if needed.
[approve]
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Windows/Program.cs (1)
132-132: Consistent error-handling pattern across platforms.
Again, NonInterrupting in development and None in production stays consistent with other client projects. Good synergy between the Windows and web clients.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/AppComponentBase.cs (1)
263-263: Switch to ExceptionDisplayKind.Interrupting Enhances Clarity
Using a descriptive enumeration instead of a bool parameter improves the readability and clarity of the exception’s intended user impact. This avoids confusion around meanings of true/false for different display modes.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/MauiProgram.cs (1)
204-204: Dynamic Exception Display Mode
This line leverages a different display mode for development vs. production. It’s a good practice to show user-friendly, less intrusive errors in dev builds, and possibly no visible errors in production. Ensure that any essential warnings still appear for debugging in dev builds.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/AuthManager.cs (1)
131-131: Replacing 'nonInterrupting' with 'displayKind'
Using 'displayKind' for distinguishing a refreshed token exception (non-interrupting) from other interrupting exceptions is a notable improvement in code clarity. This conveys the developer’s intent more explicitly.
yasmoradi
deleted the
9536-boilerplate-project-template-exception-handlers-display-exception-to-the-users-mechanism-needs-improvements
branch
2 participants
closes #9536
Summary by CodeRabbit
New Features
ExceptionDisplayKindto enhance error handling.Bug Fixes
Documentation
ExceptionDisplayKindenum.Refactor
displayKindparameter instead of the previous boolean flag.