Tôi có một dịch vụ WCF mà trả về một Stream giống như sau:Tôi làm cách nào để kiểm tra Stream.Null?
public Stream StreamFile(string filepath)
{
try
{
// Grab the file from wherever it is
// Throw an exception if it doesn't exist
return fileStream;
}
catch (Exception ex)
{
// Log the exception nicely in a place of my user's choosing
}
return Stream.Null;
}
Tôi từng cố gắng để trở về null, nhưng tôi bắt đầu chạy vào vấn đề này nếu các tập tin không thể được tìm thấy: WCF - MessageBodyMember - Stream - "Value cannot be null"
Bằng cách trở về Stream.Null, tôi đã loại bỏ lỗi đó, nhưng bây giờ tôi có một vấn đề khác - làm thế nào để khách hàng của tôi biết nếu tôi gửi lại Stream.Null? Tôi không thể/không nên kiểm tra độ dài, vì các tệp này có thể khá lớn, nhưng ngay cả khi chúng không, tôi sẽ gặp phải sự cố này: Find Length of Stream object in WCF Client?
Đây là mã khách hàng (được đơn giản hóa) của tôi , chỉ cho hậu thế, nhưng vấn đề đối với tôi chỉ cần tải về Stream.Null là tôi kết thúc với một tập tin có sản phẩm nào, và không ai thích điều đó.
public FileInfo RetrieveFile(string fileToStream, string directory)
{
Stream reportStream;
string filePath = Path.Combine(directory, "file.txt");
using (Stream incomingStream = server.StreamFile(fileToStream))
{
if (incomingStream == null) throw new FileExistsException(); // Which totally doesn't work
using (FileStream outgoingStream = File.Open(filePath, FileMode.Create, FileAccess.Write))
{
incomingStream.CopyTo(outgoingStream);
}
}
return new FileInfo(filePath);
}
Có vẻ như tôi đang thiết kế phương pháp này sai bằng cách nào đó, nhưng tôi không thể nghĩ ra cách tốt hơn để làm điều đó không liên quan đến việc ném một ngoại lệ không bị bắt. Bất kỳ đề xuất?
'Stream.Null' không liên quan gì đến' null' hoặc bất kỳ giá trị dự phòng đặc biệt nào, đây là một trường hợp dòng đặc biệt tương ứng với luồng DOS 'NUL' hoặc'/dev/null' trên Linux/POSIX. Do đó bạn không nên trả lại. – Dai
Nếu bạn đang ở trong tình trạng lỗi, hãy xem xét sử dụng hệ thống "Lỗi" của WCF được sử dụng để chỉ ra cho khách hàng rằng một phản ứng điển hình (ví dụ: với một đối tượng 'Stream' phù hợp) không thể hoàn thành. – Dai
Thêm thông báo trạng thái vào đầu luồng. Khách hàng sẽ đọc trạng thái từ đầu tin nhắn và xóa trước khi xử lý phần còn lại của dữ liệu. Làm điều này là một thiết kế mạnh mẽ rất tốt và những người nói nó là không cần thiết là loại bỏ thông tin gỡ lỗi quan trọng đó là quan trọng khi điều kiện lỗi xảy ra. – jdweng