Có nhất thiết là tôi học các câu lệnh Thử / Bắt và Cuối cùng cho Lập trình Trò chơi không, hay đó là thứ tôi có thể quay lại? [đóng cửa]

Có vẻ như không phải là một phần thiết yếu của Lập trình TRÒ CHƠI.

Họ là 100% thiết yếu. Bạn có muốn trò chơi của bạn bị sập bất cứ khi nào xảy ra lỗi không? Cấp, một số lỗi sẽ luôn gây ra sự cố, nhưng điều gì đơn giản như thời gian chờ mạng? Sẽ không thông minh hơn khi nói với người chơi và cho anh ta thử lại, hoặc kiểm tra kết nối mạng của anh ta?

Chọn chúng là rất dễ dàng.

try
{
    //open a network connection and try to get the leaderboard 
}
catch(Exception ex)  //type of exception, and a variable to access it by
{
    //tell the user something happend, and have them try again.
    //maybe you jut want to log it.

    LogError(ex);
    //so we have a record it happend, but the error was really bad! (out of memory) just throw it again if you need to
    throw;
}
finally
{
    //this happens no matter what. it will run on success and failure
}

Mặc dù tôi đồng ý với câu trả lời của Joe rằng xử lý ngoại lệ là một kỹ năng hữu ích để học hỏi, nhưng kinh nghiệm của tôi là chúng hiếm khi được sử dụng trong phát triển trò chơi.

Tôi không chắc lắm về sự khác biệt trong cách triển khai, nhưng trong C ++, chi phí liên quan đến việc giữ dấu vết ngăn xếp để cho phép giải quyết hiệu quả mỗi khi gặp phải 'ném' là lý do duy nhất khiến họ cau mày.

Câu trả lời này có thể cung cấp cho bạn cái nhìn sâu sắc hơn về các chi phí liên quan đến xử lý ngoại lệ C #.

Về mặt kiến ​​trúc chương trình chung, các trường hợp ngoại lệ không hữu ích để xác định lý do chính xác cho sự cố và gây khó khăn cho việc xác định chính xác nơi xảy ra lỗi. Bạn sẽ thư giãn đến điểm bắt, nhưng có ít hoặc không có thông tin (tùy thuộc vào tính hữu ích của ngoại lệ của bạn) về lỗi bắt nguồn từ đâu.

Tôi đồng ý rằng đó là thứ mà bạn có thể quay lại.

Có lẽ không cần thiết phải "lập trình trò chơi" theo cách có thể để bảo trì / hỗ trợ lập trình. Nói cách khác, nếu bạn có thể nghĩ "lập trình trò chơi" là kỷ luật chế tạo và phân phối trò chơi, thì lợi ích của việc xử lý ngoại lệ sẽ được đưa ra ánh sáng sau vận chuyển ngoài cửa.

Điều đó nói rằng, có những thứ có thể đóng một vai trò trong bao lâu:

• Đăng nhập của bạn. Vì vậy, sẽ có một điểm khi bạn bắt đầu xây dựng chiến lược quản lý lỗi. Việc bạn hình thành chiến lược sớm như thế nào có liên quan trực tiếp đến số lượng hỗ trợ mà bạn phải chịu từ các báo cáo lỗi và các mục nhật ký bị bắt như "tham chiếu null". Thông thường, không có bối cảnh mà bạn có thể nắm bắt từ ngoại lệ, bạn phải thực hiện nhiều công việc thám tử hơn và việc nhóm các lỗi lại với nhau sẽ khó khăn hơn, để thấy được những điểm tương đồng.

• Hệ thống vá của bạn. Nếu bạn có thể đưa ra các bản cập nhật, thì bạn có rất nhiều tự do để chờ xử lý ngoại lệ. Tương tự với nếu logic của bạn là một ứng dụng web và khách hàng chỉ là trình duyệt.

• Quy mô đội của bạn. Nếu bạn là một đội một người, thì bạn có quyền tự do rất lớn để chờ đợi. Bạn biết mã của bạn. Bạn thậm chí có thể biết trước rằng ngoại lệ nằm trong danh sách việc cần làm của bạn. Nếu bạn làm việc và chia sẻ mã với các nhà phát triển khác, bạn có thể được chỉ định một vé để theo dõi mã của người khác để bạn không thể thấy ngay ngoại lệ bị vấp ở đâu.

• Đồng thời. Đối với tôi, điều này là khó lập kế hoạch cho nó có thể không đáng nỗ lực. Ngoài ra, tôi cảm thấy đây là một phần của sự mạnh mẽ hoặc khả năng phục hồi. Vì vậy, nếu các yêu cầu cho phép sự cố bất ngờ, thì bạn có quyền tự do rất lớn và vì vậy bạn sẽ chờ đợi để giải quyết các trường hợp ngoại lệ. Một điều bạn có thể tìm thấy với các chủ đề là rất dễ để có được hành vi không xác định. Khi điều này xảy ra, bạn muốn có nhiều cách để nắm bắt càng nhiều thông tin về trạng thái dẫn đến sự thất bại. Điều này có thể bao gồm mô phỏng trong phòng thí nghiệm của máy móc, kiểm tra hồi quy, nhật ký, dữ liệu (trực tiếp). Cá nhân mỗi phần này có thể bù đắp cho những phần khác ở một mức độ nào đó. Ví dụ: nếu bạn có các bài kiểm tra vô hạn, bạn sẽ có thể phơi bày mọi lỗi logic và do đó không cần xử lý ngoại lệ (hoặc ghi nhật ký hoặc bất cứ điều gì khác).

Xử lý ngoại lệ là một cách sạch hơn để xử lý các lỗi không mong muốn từ bất kỳ điểm nào trong trò chơi. Nhưng vẻ đẹp của nó là, trong cơ sở mã của bạn, việc bạn xử lý mã này sâu đến mức nào sẽ không thành vấn đề. Không có ngoại lệ, một số loại thói quen xử lý lỗi sẽ trả về một bool hoặc int cho một loại trạng thái nào đó, sau đó mở ra các chương trình con lồng nhau cho đến khi bạn đến một khu vực cấp cao nhất (lớp trò chơi của bạn) và thoát khỏi đó. Sẽ rất khó khăn khi viết mã của bạn để kiểm tra lỗi từ bất kỳ điểm nào có thể, các máy ảnh sử dụng ngoại lệ yêu cầu ít hoặc không cần cấu trúc lại.

Vì câu hỏi của bạn là cụ thể về XNA, có lẽ sẽ rất hữu ích khi biết cách xử lý các trường hợp ngoại lệ trong trò chơi Xbox, bởi vì khi một trò chơi trong đó không bắt được, bạn sẽ không biết tại sao nó lại xảy ra. Bài viết này cho bạn thấy một cách thông minh để khắc phục điều đó bằng cách chạy toàn bộ trò chơi của bạn trong một khối thử / bắt. Nó sẽ khởi chạy một "ExceptionGame" mới nếu có sự cố xảy ra, chuyển các chi tiết về lỗi để hiển thị trong ExceptionGame.

Tôi không biết gì về C #, nhưng đây là ba xu của tôi:

1. Mô hình xử lý ngoại lệ thử / bắt / cuối cùng là phổ biến và vì lý do chính đáng: nó cung cấp một khung tuyệt vời để xử lý các ngoại lệ trong mã của bạn.
2. Nếu bạn đang sử dụng một ngôn ngữ nhất định, bạn nên tìm hiểu tất cả các câu lệnh và cách sử dụng chúng hoặc mã của bạn sẽ là một sự kết hợp khó hiểu, lỗi và không hiệu quả. Rất nhiều suy nghĩ đi vào thiết kế ngôn ngữ lập trình, và cố gắng viết một chương trình mà không sử dụng tất cả các công cụ có sẵn cho bạn chỉ là ... ngớ ngẩn.
3. Không được chê bai, nhưng có nhiều khía cạnh đầy thách thức trong phát triển trò chơi và cố gắng thực hiện nó với thái độ "Tôi sẽ chỉ học những gì tôi thực sự cần có" sẽ không kết thúc tốt. Bạn sẽ được phục vụ tốt hơn bằng cách sử dụng hành trình đến mục tiêu phát triển trò chơi của mình như một cơ hội để học hỏi nhiều nhất có thể.

Không, ngoại lệ không quan trọng hoặc thiết yếu theo bất kỳ cách nào. Đối với hầu hết các chương trình trò chơi truyền thống rất nặng về kiểm tra lỗi và biết chính xác những gì đang xảy ra với dữ liệu và tham số.

Ngoại lệ đó là khi truy cập các cuộc gọi hệ thống, chúng sẽ đưa ra các ngoại lệ và cách bắt chúng được ghi lại rất tốt và bạn có thể sử dụng thử / bắt như hộp đen cho đến khi bạn bắt đầu sử dụng ngoại lệ sâu hơn.

Toàn bộ điều try / catch là tuy nhiên rất dễ dàng để nhận và một khi bạn làm quen với C # bạn sẽ có thể để xem nơi ngoại lệ có ý nghĩa và bạn có thể bắt đầu để thêm chúng vào mã riêng của bạn một cách tự nhiên.

Tất nhiên, giả sử rằng bạn chỉ mới bắt đầu. Nếu bạn đang học C # sau các ngôn ngữ khác thì bạn nên chọn ngoại lệ và không đợi đến sau này.

Tôi tin rằng nó phụ thuộc vào bản chất của mã trò chơi của bạn. Có khu vực nào trong luồng thực hiện của bạn, nơi mọi thứ có thể thất bại? Mã của bạn được xử lý 100%? Nếu mã không có cách nào để thất bại, nếu bạn nhận thức được điều kiện đăng và chắc chắn về điều đó, thì việc xử lý ngoại lệ sẽ ít được sử dụng và đơn giản là sẽ tăng việc sử dụng tài nguyên để kiểm tra mà không có lý do. Tuy nhiên, phần lớn mã có các tình huống mà mọi thứ có thể thất bại. Đặc biệt là trong phát triển trò chơi, nếu một trò chơi có thể dự đoán được, rất có thể nó sẽ thiếu bản chất của một trò chơi. Bất kể việc sử dụng nó trong phát triển trò chơi là gì, bạn PHẢI biết về nó và cách sử dụng nó. Nhưng áp dụng nó khi cần thiết.

Bạn có muốn biết những gì đã sai trong chương trình của bạn mà không chèn các điểm dừng hoặc nhìn vào toàn bộ mã của bạn. Nếu có, thì các câu lệnh try-Catch giúp bạn làm điều đó. Nó cho bạn biết những gì đã sai khi sử dụng các loại lỗi đặt trước. Vì vậy, bằng cách thực sự học các câu lệnh này và biết lỗi nào là gì, bạn có thể gỡ lỗi mã một cách hiệu quả mà không gặp rắc rối nào.

Tốt,

Thông thường xu hướng phần mềm hướng đối tượng sử dụng Ngoại lệ để báo cáo lỗi trong bộ xử lý đang chạy. Nếu có điều gì đó xảy ra mà phương thức hiện tại không thể giải quyết / giải quyết, thì nó sẽ đưa ra một ngoại lệ và để ai đó ở cấp cao hơn xử lý vấn đề này. Nếu bạn làm theo cách này, các phương thức xử lý chính của bạn (những phương pháp cụ thể hơn) sẽ sạch hơn rất nhiều mà không cần phải xử lý các lỗi mà nó không thể giải quyết.

Nhưng thông thường, trong phát triển trò chơi Ngoại lệ không được ném vì bạn đang thiết kế sự đố kị lỗ hổng. Nếu bạn đang thiết kế Công cụ của mình, thì có, bạn sẽ sử dụng ngoại lệ cho các tính năng I / O cơ bản, nhưng trong cảnh, chẳng hạn, không có khả năng bạn sẽ sử dụng nó. Tôi thấy rằng tốt hơn hết là cố gắng thêm vào danh sách những việc phải giải quyết thay vì ném lỗi. Ví dụ: bạn có một trò chơi máy khách / máy chủ. Trong khách hàng, bạn nhận thấy một cái gì đó đã đi sai. Tôi thấy rằng tốt hơn (đối với tôi) để thêm lỗi này vào danh sách các lỗi phải giải quyết, thay vì phá vỡ chuỗi. Bằng cách đó, bạn chỉ có thể nhảy lỗi này và không ném ngoại lệ, nhưng ai đó sẽ cố gắng khắc phục vấn đề này.

Nhưng trong bất kỳ phần mềm OO nào bạn sẽ làm việc cùng, hãy nhớ rằng các ngoại lệ luôn được sử dụng. Đó là một điều thực sự tốt để học, rất hữu ích và không khó chút nào.