|
Mycroft Holmes wrote: sn't that the definition of stupid - repeat the same action with the same settings and expect different results!
It is stupid, until it works. Which will be just when I{m showing nmy wife that it won{t work.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Sounds quite probable to me - I was debugging the call stack for an EF connection yesterday.
I happened to be connecting to a SQL Server database, however as System.Data was being referenced the call stack showed all sorts of database connection types(probably the wrong term but you get my drift?) being tried for the connection, including Oracle.
It's kind of clever that it takes away me having to specify the type of database EF is connecting to, while at the same time being rather horrifying that it tries different connection types until it succeeds.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Could have been worse...
A MysteriousException , or a ConfusingException instead.
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
|
...or even worse: GeneralException - exception that can be anything from anywhere.. sorry, no stack.
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
|
OutOfMemoryException is what happens, invalid format is the reason for it.
This is the recurring question of whether one should catch the error and throw a new different error instead, or if you should let the original error propagate upwards.
I prefer the former if I don't have control over the code.
|
|
|
|
|
I would just prefer they sniff the image file to ensure they can handle it instead of blindly trying to load it and then finding they are out of memory (and I get that they check and abort before using up all memory, but the point remains)
cheers
Chris Maunder
|
|
|
|
|
I believe that verifying a compressed image would go through exactly the same steps as parsing it would.
This is probably the most efficient way.
The error message is still stupid though.
|
|
|
|
|
In the case that affected me it was an attempt to load an SVG file which I discovered isn't supported. A simple check of filename or the first few bytes of the file would have found this. There's even a handy list[^] they could refer to.
cheers
Chris Maunder
|
|
|
|
|
I was told by my boss the other day that my biggest weakness is that I always assume people do thing properly.
|
|
|
|
|
cheers
Chris Maunder
|
|
|
|
|
Extensions aren't trustworthy, nothing guarantees the file is in the format it says it's on. The developer himself might have changed the extension to better suit his application, as evidenced by the shitload of formats that are just XML files, compressed or not, with a different extension (like SVG).
As for the first few bytes, many formats have common prefixes (there's 2 or 3 exemples on the list you linked, but there's more), some of them don't even require the prefix to be present and others (like SVG) are encoded as text that can have yet another prefix (BOM).
It's sad, but we can't trust the format markers when dealing with multiple formats.
|
|
|
|
|
Because the actual internal error being thrown is an OutOfMemoryException. That has been my experience, especially when working with LEADTools libraries and images with OCR software.
Edit: I have seen this similar thing happen before, and for some reason the image "may" be corrupted and thus causes a memory issue. Then the developer just returns a crap message saying not a valid image format. But in reality, the software kept reading the bytes until it ran out of memory.
|
|
|
|
|
Because a useful name for the exception was out-of-the-memory of the developer.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
The GDI classes seem to be simply a .net facade\interface to the actual underlying code and that code only seems to return generic error messages that are of no help at all. Any issue that happens with GDI simply returns "A generic error occured" even if the error has a specific cause. So I'm going to guess that the reason better exceptions are not thrown is simply because the .net part of the equation doesn't know what the problem is as GDI only bubbles up weird or vague error messages.
|
|
|
|
|
The return exception is known: out of memory. I have a lot of experience with OCR and images, etc. and this is a common error in underlying C++ libraries when reading the bytes of an image, etc.
So, the error is factual and known: out of memory error, usually attributed to an corrupt file format.
The user friendly message is still mostly accurate here. It should say something like "your image file format is incorrect or corrupted as the software was unable to process it without error." -- or something like that.
|
|
|
|
|
In a moment of clarity, I recalled the answer: they are applying the Maunder Minimum. 8)
|
|
|
|
|
Chris Maunder wrote: and using something like UnsupportedFormatException is too hard?
Just be glad its not the usual, "Error occurred", Good luck figuring it out.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
Looks like it's the same reason why renaming an EXE to COM and trying to load it generates an "Out of memory" error: Implementation details leaking to the surface.
|
|
|
|
|
I mean, not really? COM files have a size limit because they behave different from EXE files (or rather, EXE files behave different, since COM is the original). When you try to load a COM file that exceeds this limit you're really running out of memory, before the code can even start to be executed.
Could they read the file size and predict that? they couldn't (or just didn't, hard to say with stuff this old) when COM files where actually being used, so the current included loaders also don't. You don't really want to mess with those kinds of legacy systems, specially when they are useless for current developments and the alternative doesn't share the concerns.
COM file - Wikipedia
|
|
|
|
|
Don't care, I always use
catch(Exception e){..} That always works
|
|
|
|
|
I was watching a very good intro to Functional programming on PluralSight (Functional Programming with C# | Pluralsight[^]) and the author / presenter created the following method (mine has altered var names).
public static class Helper{
public static T Tee<T>(
T @inVal,
Action<T> act){
act(@inVal);
return @inVal;
}
}
Now you can call that method like the following:
Helper.Tee("test", Console.WriteLine);
Helper.Tee(3.238, Console.WriteLine);
Helper.Tee (new {garbage="super"},Console.WriteLine);
Here's the output:
test
3.238
{ garbage = super }
It's loosely based on the following idea (why it's named Tee): tee (command) - Wikipedia[^]
Just thought it was an interesting example and it made me think differently about things.
After all these years of OOP I'm beginning to see the real value in the Functional paradigm*.
*Obviously the included sample is not a huge example of Functional programming in and of itself.
|
|
|
|
|
How is that any different from calling Console.WriteLine("test"); etc.?
It's just more code to call Console.WriteLine and you aren't chaining anything or using the Tee output
Even worse, an Action<T> assumes a side-effect because it doesn't return a value.
Or is Tee used to "hide" this side-effect?
If I read the wiki page I'd suspect Tee does the Console.WriteLine and you can pass in a File.WriteText or something similar, but even then I fail to see how Tee is helping you. You could just as well call both methods.
|
|
|
|
|
I like your questions because I'm learning the concepts and determining how these things are important too. And I can tell by your questions that you have more functional experience than I do.
Here's an example that may make more sense -- it's like a before and after test.
Helper.Tee(Helper.Tee(" _ before after _ ", Console.WriteLine)
.ToUpper().Trim()
.Substring(8,6),
Console.WriteLine);
That results in an output like the following:
_ before after _
AFTER
Because the Tee method returns the value methods can be chained just like the normal string methods and so you can see the BEFORE version of your string and then the AFTER version.
I don't know if that is helpful either, but it's interesting.
This was a very small portion of an example showing how to create fluent APIs.
|
|
|
|
|
This definitely looks like a case for an extension method[^].
" _ before after _ "
.Tee(Console.WriteLine)
.ToUpper().Trim()
.Substring(8, 6)
.Tee(Console.WriteLine);
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|