Error handling in .Net

[myl]

Hey Laurent and other SFML users.

I'm currently moving a project from SDL to SFML. Happy times, except when it comes to error handling. Going through forum threads on the topic I understand this is not an easy fix. Typed errors is a luxury, but I would be happy if I can just reroute or catch the messages in std err somehow. Has anyone had luck with this? This does not work for me: http://stackoverflow.com/questions/1579074/redirect-stdoutstderr-on-a-c-sharp-windows-service

I've attempted to make a wrapper around the sf::err stream in the excluded SFML System module, but with no luck, as a am merely a mortal C# developer.

Help! I need my errors!

[Laurent]

Aren't the exceptions thrown by SFML.Net enough for you? Why do you want to catch the original SFML messages?

[myl]

The LoadingFailedException provides no information to my knowledge? I would very much like to log the reason to have any chance of debugging whenever a user reports an error. It also seems a lot of useful information is being outputted without throwing exceptions.

[Laurent]

Ok, I see.

I'm sorry I can't help (if I could, it would be done directly in SFML.Net ).

[myl]

Would it make sense to expose a function that takes a stream or filehandle/filepath to reroute the stderr?

[Laurent]

I don't know. I'm not very satisfied with the way I handle errors (I mean on the C++ side), so I'd rather think about a different error management system, instead of "fixing" the current one.

[myl]

Hmm, this is now causing me a lot of pain, i have 100+ users reporting texture load error on the same hardware, but no way of catching the sfml output. Any ideas much appreciated!

Merci!
myl

[Laurent]

For debugging you can run the app with a redirection of the standard error output to a file, for example.

myapp 2> errors.txt

[myl]

Something funny is going on because that does not work, and I suspect the code example mentioned earlier doesn't work for the same reasons (essentially the same).

I tried redirecting stderr from command and also tried redirecting everything, but the output file doesn't contain sfml output. The console window no longer displays sfml output, and a file is generated but i have no clue where the output goes.

I remember reading somewhere that some compilers do interesting stuff related to redirection. What was the pre-built csfml binaries in the win 32bit .Net package built with?

[Laurent]

The console window no longer displays sfml output

So you already have the SFML error output in the console? So you can see what happens for the loading failure?

I remember reading somewhere that some compilers do interesting stuff related to redirection. What was the pre-built csfml binaries in the win 32bit .Net package built with?

I don't do anything special regarding redirections.

[myl]

I get console output locally yes (when I don't redirect), but I am unable to reproduce the loading failure in question, which is why i need to figure out how to collect debug info in the field.

Pretty strange the output disappears into thin air when redirected.

[Laurent]

I get console output locally yes (when I don't redirect), but I am unable to reproduce the loading failure in question, which is why i need to figure out how to collect debug info in the field.

Ok, so you're not completely blocked, you can distribute a build with console to one user who is able reproduce the error.

Pretty strange the output disappears into thin air when redirected.

It must go somewhere. Do you run the app from Visual Studio? If so, the working directory is not the executable directory, it's the project directory by default.

[myl]

Ok, so you're not completely blocked, you can distribute a build with console to one user who is able reproduce the error.

Reproduction frequency is very low unfortunately, but since we have many users, i get a lot of reports. Hard to find a single point of manual testing. :/ And I would have to go some places i am not comfortable with in a production environment (keeping console windows open after crashes is suboptimal).

It must go somewhere. Do you run the app from Visual Studio? If so, the working directory is not the executable directory, it's the project directory by default.

The file is created and whatever debug output i throw at Console.Out lands in it, excluding the sfml out. Meaning the sfml output is redirected, but not to the same place as the .Net generated out.

[Laurent]

The file is created and whatever debug output i throw at Console.Out lands in it, excluding the sfml out. Meaning the sfml output is redirected, but not to the same place as the .Net generated out.

Ah, I see. This is really strange.

[myl]

From the comments in this post:
http://stackoverflow.com/questions/2215312/getting-stdout-when-p-invoking-to-unmanaged-dll
i understand that there could be issues with redirection of stdout/stderr for MinGW compiled dlls on windows. Are the 32bit windows csfml dlls MinGW compiled?

Merci!
myl