110,499
社区成员
发帖
与我相关
我的任务
分享
public static Stream ToStream(Image image)
{
ImageFormat format = image.RawFormat;
MemoryStream ms = new MemoryStream();
image.Save(ms, format);
return ms;
}
你占了坑,有时间再写也填不了你占的这个位置的坑。 我先占个坑,再找时间来写写。
/// <summary>
/// 保存图片
/// </summary>
/// <param name="i"></param>
/// <param name="format">图像格式</param>
/// <param name="value">图片质量(1-100)</param>
/// <returns></returns>
/// <exception cref="NullReferenceException">Image 不能为 null</exception>
/// <exception cref="InvalidOperationException">不支持的 ImageFormat</exception>
/// <exception cref="ExternalException">该图像以错误的图像格式保存</exception>
public static MemoryStream Save(this System.Drawing.Image i, ImageFormat format, int value)
{
MemoryStream stream = new MemoryStream();
if (i.RawFormat == ImageFormat.Gif)
{
using (System.Drawing.Image gif = ImageExtensions.Quantizer.Quantize(i))
{
try
{
gif.Save(stream, format.ToImageCodecInfo(), value.ToEncoderParameters());
}
catch (ArgumentNullException)
{
throw new InvalidOperationException("不支持的 ImageFormat");
}
}
}
else
{
try
{
i.Save(stream, format.ToImageCodecInfo(), value.ToEncoderParameters());
}
catch (ArgumentNullException)
{
throw new InvalidOperationException("不支持的 ImageFormat");
}
}
//重置数据流位置
stream.Position = 0;
return stream;
}
/// <exception cref="System.NullReferenceException">异常描述</exception>
/// <exception cref="System.ArgumentException">异常描述</exception>
/// <exception cref="System.Runtime.InteropServices.ExternalException">异常描述</exception>
public static Stream ToStream(Image image)
{
//System.NullReferenceException
ImageFormat format = image.RawFormat;
MemoryStream ms = new MemoryStream();
try
{
//System.ArgumentNullException
//System.Runtime.InteropServices.ExternalException
image.Save(ms, format);
}
catch (System.ArgumentNullException)
{
throw new System.ArgumentException("找不到图片的原格式");
}
return ms;
}
比如说,你检查 image 的大小,当它的颜色偏“黄颜色”的时候你跑出了一个自定义的 Exception,那么这是你的业务逻辑就是这样设计的。这个时候你可能会给别人一个文档说明这个抛出的自定义的异常的业务含义。 但是假设要任何人都罗列一些好像是“全面”的各种畅想,把任何可能的跟他的业务自定义设计无关的 Exception 都罗列出来,这就完全纠结概念而在实践中跑出了边际,跑到火星上去编程了。根本没有必要因为这种原因而忧心忡忡地去担心什么,根本不需要 try...catch。 要不要 try...catch,在于你开发中是不是主动测试。有的人只会盲目照抄例子,而不是以测试为驱动,那么他永远都是被动的思路,他永远不是在改进而是永远都在防御。
这个问题根本没有考虑到实际的原因,所以答案其实会偏离软件工程的目标。 你的 Release 的版本就是要容错所以当然需要 try...catch;而你的 Debug 版本就是要通过上万次测试回归让 debug 尽早跳处理来强迫系统进入调试环境,那么自然就应该尽可能去掉 try....catch。纠结它的名词儿概念,其实往往是根本没有直接进入其使用方法的,这就好像一个静止在树根底下不动的人永远追不上兔子一样,虽然好像知道“是什么”但是总也搞不明白“如何做”。 为什么要在 debug 的时候要让 bug 尽早调出来?因为只有 image 为 null 时造成的 bug 你才能追查一系列的软件设计 bug 嘛!开发时的目的就是求真,而不是自欺欺人。只有高强度的测试机制,你才知道该做什么事情,而不是“带着病”去写更多有毛病的代码。 但是 Release 版你自然就要容错。仅当你有几万、几十万次的测试,这时候在 Release 版本中再让“必要的” 几个 try...catch 起作用,这就好像是民航飞机都至少有两套飞行控制系统,它不是为了自欺欺人所以才冗余,而是在它每一套飞行控制系统都已经千锤百炼了之后仍然在 Release 版本中增加一个容错。这才是真正的容错思路。如果你认为 try...catch 就是为了隐瞒错误才这写代码,那么你从一开始就学了最令程序员不齿的开发观念了。
我先占个坑,再找时间来写写。