2015-09-12 16 views
13

Nếu chương trình .net không đặt rõ ràng mã thoát trước khi chấm dứt (bằng cách gọi Environment.Exit()/Appliation.Current.Shutdown()/...), mã thoát cho quy trình đó là gì?Có thể dùng chương trình .net nào khi không sử dụng Environment.Exit()?

Việc chấm dứt bình thường có luôn dẫn đến mã thoát không và các trường hợp khác có thể là gì?

Theo this answer cho câu hỏi có liên quan Getting ExitCode From Exception Handler bởi Hans passant: "nếu một chương trình chết trên một ngoại lệ sau đó mã thoát của nó là thường giống như các ngoại lệ cơ bản mã lỗi".

Vì vậy, ngoại lệ uncaugth có thể xử lý mã thoát. Đây có phải là luôn luôn trường hợp và mã lỗi ngoại lệ cơ bản luôn được đảm bảo là khác với số không và trong một phạm vi cụ thể không? Có những trường hợp khác mà khung .net hoặc Windows có thể tự động đặt một mã thoát khác, chẳng hạn như một số sự cố không liên quan đến ngoại lệ (có thể xảy ra không?), Hoặc một nhiệm vụ bắt buộc bị giết?

Để đặt nó theo một cách khác, tôi có thể xác định bằng mã thoát cho dù chương trình chấm dứt trong bất kỳ thời trang bất thường nào hay không?
Hoặc nếu mã thoát bằng 0 có thể xảy ra trong một số trường hợp bất thường, tôi có thể bao gồm Environment.Exit(somevalue) trong tất cả các đường dẫn chấm dứt bình thường cho chương trình hay không và đảm bảo rằng mã thoát này không bao giờ có thể xảy ra trong trường hợp xảy ra sự cố?


Động lực:
Kể từ not all exeptions are catchable mà không giải quyết nghiêm trọng, và vì có thể có những nguyên nhân khác cho việc chấm dứt chương trình bất ngờ khác ngoài excpetions còn tự do, đảm bảo rằng tất cả các đường dẫn mã gọi Environment.Exit() là không alwas càng tốt. Đây là lý do tại sao tôi quan tâm đến việc xác định xem mã thoát có thể được sử dụng để cho biết một chương trình có được thoát bình thường không.

+0

Tôi đã thêm sự khác biệt giữa câu hỏi của tôi và bản sao được đề xuất. Trong khi câu trả lời thứ hai cũng giúp với một phần của câu hỏi của tôi, nó không hoàn toàn trả lời nó, và câu hỏi chính nó là hoàn toàn khác nhau. – HugoRune

+0

Đề xuất về mặt tình cảm: bật Báo cáo lỗi Windows, với tùy chọn tạo minidumps được bật. Bằng cách đó bạn không chỉ có một mã thoát, mà còn là các bản ghi ngoại lệ và các ngăn xếp một phần mà bạn có thể đi qua một trình gỡ lỗi. (Giống như WinDBG bằng cách sử dụng trình gỡ rối SOS.) Ngay cả khi không có minidumps WER sẽ nắm bắt một số thông tin về chính thông báo lỗi. Đối với một ứng dụng nội bộ, bạn thậm chí có thể thiết lập một máy chủ cho các báo cáo sự cố được gửi tự động. [Trang] này (https://technet.microsoft.com/en-us/library/cc709644.aspx) trên TechNet có tổng quan tốt. – theB

+0

Mã thoát là IMHO vô dụng. Thêm tại đây: http://stackoverflow.com/questions/4344923/process-exit-code-when-process-is-killed-forcibly –

Trả lời

5

sau đó mã thoát của nó là thường giống như các mã lỗi ngoại lệ cơ bản

Sau 6 tháng, bạn nên đã xây dựng được một số tin tưởng rằng thường áp dụng. Có thể làm việc tốt, bạn chỉ không thể nhận được bảo hành ở đây. Nó không chỉ là các ngoại lệ không được xử lý mà làm cho một quá trình chấm dứt và bạn không bao giờ có thể chắc chắn rằng nó luôn luôn là cùng một mã chạy khi một tiến trình chết trên một ngoại lệ.

Có quá nhiều thứ ngoài kia muốn tham gia và điều này không phải lúc nào cũng có chất lượng tốt nhất. Trên đầu danh sách chắc chắn là phần mềm chống phần mềm độc hại, có rất nhiều phần mềm độc hại trên đó và bạn sẽ không bao giờ biết những gì bạn gặp phải. Thảm họa Avast gần đây đưa ra rất nhiều lý do để lo ngại về điều này. Không gần nơi nó kết thúc, các tiện ích thay thế WER là đủ phổ biến.

Và bạn hoàn toàn tự vệ chống lại một yokel nghĩ rằng TerminateProcess() là một cách tốt để giải quyết vấn đề khóa tệp. Hoặc ai đó vấp phải dây nguồn và rút máy.

Tập trung một chút vào số lý do tại sao bạn muốn biết mã thoát.Có phải là một cái gì đó bạn làm tiếp theo mà sử dụng kết quả của chương trình để tiếp tục thực hiện. Xác nhận kết quả.

2

Quy trình bạn đang thực hiện của riêng mình? Tức là, bạn có thể kiểm soát mã thoát của nó trong các trường hợp dự đoán được không? Nếu vậy, bạn có thể bắt bất kỳ trường hợp ngoại lệ nào được ném và sau đó trả lại mã ngoại lệ có thể dự đoán của riêng bạn (một giá trị cụ thể hoặc phạm vi của riêng bạn.) Tôi sẽ sử dụng số âm vì mã lỗi hệ thống là dương. Bằng cách đó bạn đã có ba khả năng:

  1. Zero - thành công
  2. Negative - quá trình ném một ngoại lệ mà bạn đã có thể bắt
  3. Positive - quá trình ném một ngoại lệ mà bạn không thể nắm bắt. Đó sẽ là bất thường.

Bất kỳ điều gì khác ngoài điều đó dường như không thể đoán trước. Nếu có điều gì đó vượt quá mức bình thường mà một quá trình thậm chí không thể trả lại mã thoát khác 0 thì quá trình chờ mã thoát đó cũng có thể không thành công. Việc kiểm tra mã thoát khác không là những gì bạn có thể làm một cách hợp lý để giải thích khả năng thất bại do bất kỳ nguyên nhân không lường trước được nào.

Tôi không biết liệu # 3 có khả thi hay không, nhưng nếu bạn đang cố gắng giải thích cho tài khoản chưa biết thì đó có lẽ là điều bạn có thể làm nhiều nhất.

Dưới đây là một ví dụ:

internal class Program 
{ 
    private static void Main(string[] args) 
    { 
     var exitCode = 0; 
     try 
     { 
      //do something 
     } 
     catch (SystemException systemEx) 
     { 
      //log 
      exitCode = -systemEx.HResult; 
     } 
     catch (Exception ex) 
     { 
      //log 
      Environment.ExitCode = int.MinValue; 

     } 
     Environment.ExitCode = exitCode; 
    } 
} 

Đó là những gì bạn có thể làm. Nhưng tôi sẽ không sử dụng mã thoát để mô tả lỗi. Tôi muốn sử dụng đăng nhập cho điều đó. Tôi muốn sử dụng mã thoát để báo cho ứng dụng gọi điện phải làm gì. Zero hoặc khác không có lẽ là đủ cho điều đó. Tôi đã viết mã trả về phức tạp hơn cho biết sự thất bại liên quan đến IO hay liên quan đến SQL và cuối cùng tôi không bao giờ sử dụng bất kỳ mã nào. Nếu nó không thành công, tôi nhìn vào nhật ký của mình để tìm một thông báo lỗi.

Các vấn đề liên quan