Jaki typ wyjątku do rzucania w tym przypadku?

Question

Piszę aplikację C#, która używa automatyzacji do sterowania innym programem. Oczywiście ten program musi działać, aby mój program działał. Kiedy mój program szuka aplikacji i nie może jej znaleźć, chciałbym rzucić wyjątek (na razie później mógłbym oczywiście spróbować otworzyć aplikację lub powiedzieć użytkownikowi, żeby ją otworzyć, lub ...).

Czy mogę zaimplementować niestandardowy wyjątek - lub użyć istniejącego wyjątku NotSupportedException (lub jednego z innych wyjątków .NET). Jeśli niestandardowy wyjątek, co byś zasugerował? Myślałem o implementacji wyjątku niestandardowego, który nazwałbym MyAppNameException, a następnie użyłbym tej wiadomości, aby zadeklarować, jaki jest problem?

Czy istnieją ogólne zasady dotyczące zgłaszania wyjątków w sposób, który powoduje, że program jest bardziej czytelny i przyjazny dla użytkownika, czy też po prostu zbytnio się nad tym zastanawiam :)?

Dzięki!

Answer 1

1. Najpierw zdefiniuj MyAppCustomException jako abstrakcyjną klasę podstawową.

2. Następnie odziedziczą po nim AppNotFoundCustomException.

ten sposób można złapać wszystkie wyjątki od aplikacji, czy tylko konkretnych nich.

Oto niektóre przykładowy kod, który ilustruje koncepcję:

public abstract class MyAppCustomException : System.Exception 
{ 
    internal MyAppCustomException(string message) 
     : base(message) 
    { 
    } 

    internal MyAppCustomException(string message, System.Exception innerException) 
     : base(message,innerException) 
    {    
    } 
} 

public class AppNotFoundCustomException : MyAppCustomException 
{ 
    public AppNotFoundCustomException(): base("Could not find app") 
    { 
    } 
} 

A oto klientowi try/catch przykład:

try 
{ 
    // Do Stuff 
} 
catch(AppNotFoundCustomException) 
{ 
    // We know how to handle this 
} 
catch(MyAppCustomException) // base class 
{ 
    // we don't know how to handle this, but we know it's a problem with our app 
} 

Answer 2

Framework Guidelines book że używam wskazuje, że należy utworzyć tylko niestandardowy wyjątek, gdy warunek błędu może być programowo obsługiwany w inny sposób niż jakiekolwiek istniejące wyjątki.

W twoim przypadku, jeśli chcesz utworzyć niestandardowy wyjątek w celu uruchomienia programu instalacyjnego zaplecza, jest to unikalne i myślę, że niestandardowy wyjątek byłby w porządku.

W przeciwnym razie odpowiednia może być dziedzina z hegemonii System.Runtime.InteropServices.ExternalException.

Answer 3

Tak, przesadzasz. Nic dobrego nie stanie się, gdy rzucisz wyjątek, każdy wyjątek, że program nie zacznie się magicznie, kiedy to zrobisz. Mogą się zdarzyć tylko złe rzeczy, np. Jakiś kod rzeczywiście wychwytuje ten wyjątek i próbuje kontynuować. Lub nikt go nie łapie i nie dostaje okna dialogowego raportu o błędach systemu Windows. Równie dobrze może wstawić okienko z wiadomościami i nazwać je jednym dniem za pomocą Environment.Exit().

Oczywiście może być bardziej przydatny dla użytkownika, jeśli faktycznie uruchomi się ten program, jeśli okaże się, że nie jest uruchomiony.

Answer 4

Z pewnością nie powinieneś używać NotSupportedException, jak sugerujesz, ponieważ twoja aplikacja obsługuje tę metodę. NotSupportedException jest używany, gdy interfejs lub klasa abstrakcyjna jest zaimplementowana, ale niektóre elementy nie są w pełni zaimplementowane, ponieważ nie mają sensu w kontekście (czytanie ze strumienia wyjściowego, czyszczenie kolekcji tylko do odczytu, itp.).

Dokładniejsze dopasowanie to coś InvalidOperationException, w którym można użyć elementu, ale nie podając bieżącego stanu.

Mówisz "aplikacja", która sugeruje plik wykonywalny, a nie komponent do użycia przez coś innego. W tym przypadku nie zamierzasz zburzyć wyjątku do kodu wywołującego (ponieważ nie ma kodu wywołującego), ale podnieś okno dialogowe (dla aplikacji GUI) lub napisz do Console.Error (dla aplikacji konsolowej). Powoduje to, że prawdopodobnie pokaże się wartość właściwości Message wyjątku lub po prostu potrzebujesz typu klasy do oznaczenia konkretnej wiadomości. Albo po prostu czerpiąc AppNotRunningException z wyjątku lub po prostu używając Exception bezpośrednio prawdopodobnie będzie służył doskonale, w zależności od tego, który z dwóch najbardziej wygodne.