Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-interest Archive, January 2008
Suggestion: Add QLibrary::errorCode() method

Message 1 in thread

with the error codes corresponding to the current error messages.

It would allow apps to retrieve a code that can be converted into
an application-specific error message (or do whatever is appropriate)
without the need to parse QStrings to determine what's gone wrong.

-- 
 [ signature omitted ]
Message 2 in thread

Stephen Collyer wrote:
>with the error codes corresponding to the current error messages.
>
>It would allow apps to retrieve a code that can be converted into
>an application-specific error message (or do whatever is appropriate)
>without the need to parse QStrings to determine what's gone wrong.

Why are you parsing the error string in the first place? What are you 
going to try and fix at runtime?

-- 
 [ signature omitted ]

Attachment: signature.asc
Description: This is a digitally signed message part.

Message 3 in thread

Thiago Macieira wrote:
> Stephen Collyer wrote:
>> with the error codes corresponding to the current error messages.
>>
>> It would allow apps to retrieve a code that can be converted into
>> an application-specific error message (or do whatever is appropriate)
>> without the need to parse QStrings to determine what's gone wrong.
> 
> Why are you parsing the error string in the first place? What are you 
> going to try and fix at runtime?

I'm not going to fix anything at runtime. I merely want the
information currently available in the errorString() message
also available in a form more amenable to use in code. The
errorString() data is really only useful for displaying to
a user, but an app. may want to branch on the specific problem
to do additional, error specific work.

-- 
 [ signature omitted ]
Message 4 in thread

Stephen Collyer wrote:
>I'm not going to fix anything at runtime. I merely want the
>information currently available in the errorString() message
>also available in a form more amenable to use in code. The
>errorString() data is really only useful for displaying to
>a user, but an app. may want to branch on the specific problem
>to do additional, error specific work.

I understood that. I want to know what kind of error-specific work you are 
thinking about. I.e., I want to understand your use-case to determine 
what kind of errors would be interesting to you.

-- 
 [ signature omitted ]

Attachment: signature.asc
Description: This is a digitally signed message part.