Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: More detailed exceptions  (Read 4984 times)

0 Members and 2 Guests are viewing this topic.

Xeon06

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
More detailed exceptions
« on: April 22, 2010, 07:52:59 pm »
Hey folks,

I was wondering if it could be possible to incorporate more detailed exceptions in SFML 2.0. For example, I just tried to load a .gif image and it gave me an exception, "Failed to load image from file test.gif." However, I noticed that in stderr there is a more detailed exception, "Reason: image not of any known type or corrupt." I searched within LoadingFailedException and I couldn't find this message anywhere. Could we maybe get the reason at runtime without having to read from stderr?

Thanks!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
More detailed exceptions
« Reply #1 on: April 22, 2010, 10:29:49 pm »
Probably. How can I get the messages from stderr in C#?
Laurent Gomila - SFML developer

Spodi

  • Full Member
  • ***
  • Posts: 150
    • View Profile
    • http://www.netgore.com/
More detailed exceptions
« Reply #2 on: April 22, 2010, 11:48:35 pm »
I'm not seeing any pretty way to do this. Even if you do grab the text from stderr, its not always going to be easy to determine what part of it is related to the error you are handling.

I personally can't come up with any decent way to do this. Exposing a "Last Error" method would probably be a pretty easy approach, but not thread-safe, and quite ugly. There is also the issue of whether you only expose the last message (in which case, problems that create multiple messages lose all but the last message) or show all messages since last call (in which case, you can end up with excessive messages if you don't call it constantly).

What about a combination of returning error codes on function calls (instead of just true or false for success/fail), along with printing to the standard streams? Assigning all of the messages an integer-based ID then providing a look-up table for the message would also make it easy to localize the messages. Could then even include these events in the Event list from Window.Event so people could (eventually) print the errors in whatever way they please. Wouldn't be very useful for handling errors, would help with logging and error tracking.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
More detailed exceptions
« Reply #3 on: April 23, 2010, 10:31:07 am »
The problem is that some of these messages are outputed by low-level libraries used by SFML (like SOIL), I have no control on them.
Laurent Gomila - SFML developer

Xeon06

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
More detailed exceptions
« Reply #4 on: April 25, 2010, 01:55:55 am »
Hmph. System.Console.Error gives you a stream to stderr, but I see the problem. I thought those messages were written there by you, that's why I asked here. Oh well, I can live with it I guess.

Side question that doesn't deserve a thread: Why are RenderWindow's Width and Height properties set to 0 upon window closing?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
More detailed exceptions
« Reply #5 on: April 25, 2010, 12:52:59 pm »
Quote
Why are RenderWindow's Width and Height properties set to 0 upon window closing?

Because the actual window no longer exists.
Laurent Gomila - SFML developer

 

anything